From: Shailabh N. <na...@us...> - 2001-01-26 15:06:17
|
Some numbers for the theory that increased performance of the MQ scheduler is causing more receiver threads to sleep waiting for data (not yet posted by sender threads). We ran a modified chat room , in which every sender thread (on server and client side) is given a priority boost of 2 before it starts. That increases the likelihood of messages being sent. The preliminary results from a 4way system are as follows (comments below). All numbers are the througputs reported by the chat room. Vanilla refers to 2.4.1-pre8, MQ to the 2.4.0-mq1rt patch applied to 2.4.1-pre8. Each value is averaged over 5 runs (statistically better runs are being conducted now). 10 rooms/100 msgs MQ Vanilla Diff No boost 133167 152765 19598 Boost=2 173311 179843 6532 10 rooms/200 msgs MQ Vanilla Diff No boost 142533 154945 12412 Boost=2 177076 176494 -582 20 rooms/100 msgs MQ Vanilla Diff No boost 130950 139145 8195 Boost=2 160392 163974 3582 20 rooms/200 msgs MQ Vanilla Diff No boost 150514 138975 -11539 Boost=2 175223 166575 -8648 Applying the boost to sender threads clearly reduces the difference between MQ and vanilla. in all cases. So doing a simple priority boost to both (for fairness of comparison) is one possible way of eliminating the tying of senders/receivers that we were seeing. Along the same lines, we could explore : - giving a boost only to server send threads - increasing the priority boost values besides running the same tests as above with more runs for statistical reasons. Shailabh Nagar (914) 945 2851 na...@us... Hubertus Franke/Watson/IBM@IB...@li... on 01/25/2001 02:36:51 PM Sent by: lse...@li... To: Mike Kravetz <mkr...@se...> cc: Bill Hartner/Austin/IBM@IBMUS, lse...@li... Subject: Re: [Lse-tech] reschedule: - MQ scheduler We are currently trying to boost the priority of the server threads and see whether that makes any difference. We could also try another combination namely raise priority of all sender threads in the system. I think this makes sense to figure out where the problem lies. Shailabh is working on that as we speak. Mike as discussed yesterday, we will post all the relevant numbers that we have right now. We collected for 1,2,3,4,5,6,7,8 way information on 2.4.1-pre8 (vanilla, MQ, prio) sched_yield_test (1--16,32,256,..,2048) threads Chatroom (10-30)Rooms x (100-300) messages Hubertus Franke Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) , OS-PIC (Chair) email: fr...@us... (w) 914-945-2003 (fax) 914-945-4425 TL: 862-2003 |