The Chat benchmark was run for three different configurations ranging from 10 rooms, 100 messages per user to 30 rooms, 300 messages. For brevity, these configurations are labelled (10,100), (20,200) and (30,300) where the first number refers to the number of rooms and the second one refers to the number of messages.
The results for the 4x4-way NUMA system with poolsize 4, 8 and 16 are shown in Table 6. MQS improves over DSS between 277% and 482% for this scheduler intensive benchmark. For PMQS, in general we observe the almost inverse behavior when comparing Chat and Mkbench. Here, all PMQS versions either substantially underperform MQS or break even. The higher the load, the worse the performance degradation. Increasing the poolsize also increases the performance for all PMQS but LBP-45. The reason for this is that Chat has, due to the send/recv interactions between threads, rapidly changing runqueue lengths, which then trigger load balancing as observed in Figures 4-6. It is likely that the frequent load balancing leads to continuously moving tasks, often before they get a chance to run. Investigating this aspect is part of our future work.
We now turn our attention to the SMP case to answer the question whether pooling within an SMP provides benefits. The results are shown in Table 7. With the exception of LBC at very high load, PMQS substantially underperforms MQS. PMQS still outperforms DSS. Two general trends can be observed within each category. Performance increases for any given load and LB algorithm with increasing the poolsize and performance increases with load.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||