Bug #1183


Interactive performance regression since 2.0 (patch #2)

Added by dillon about 13 years ago. Updated about 13 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Ok, here's a new patch to try:

This turned into a three-day marathon run but I'm really happy with
the results.
The old scheduler had a huge number of issues.  I can't count the number
of issues I came across. I had to substantially rewrite the logic.
The new user scheduler does not depend on the helper threads when
switching under load. It uses a very cool algorithm whereby threads
trying to return back into user mode 'bid' for the single user mode
slot (per-cpu). So if thread A bids the best priority so far,
then switches to thread B (also trying to exit to user mode) which
bids a better priority, thread B will directly deschedule thread A
and take over the bid. The scheduler helper is only used to kick
idle cpus to pick up the threads that lost the bid. This results in
highly optimal operation.
I also found an issue with MP lock contention on SMP boxes.  If the
LWKT scheduler could not acquire the MP lock it would continue looking
for threads that didn't need it. Sounds great, but what was happening
was that the scheduler was skipping important kernel threads needing
the lock and scheduling cpu-intensive user threads, and then not
rescheduling for a whole tick. I created two fixes for this issue
controllable live with a sysctl.
lwkt.chain_mplock=0        Causes the LWKT scheduler to refuse to
schedule a user thread if kernel threads
exist which need the MP lock but couldn't
get it.
lwkt.chain_mplock=1        Causes the LWKT scheduler to schedule the
user thread but adds logic to rel_mplock()
to attempt to IPI some other cpu needing
the MP lock, creating an event that allows
that other cpu to reschedule out of the user
I intend to commit this on Friday baring problems, so please test both
So far on my desktop I have tested lwkt.chain_mplock=0 with excellent
Matthew Dillon

Also available in: Atom PDF