Interactive performance regression since 2.0 (patch #2)

Erik Wikström Erik-wikstrom at telia.com
Wed Dec 17 12:38:18 PST 2008


On 2008-12-17 07:28, Matthew Dillon wrote:
>     Ok, here's a new patch to try:
> 
> 	fetch http://apollo.backplane.com/DFlyMisc/sched02.patch
> 
>     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.

Did I get this right? Lets say that thread A wants to go back to user
mode, and since no other threads are running it does that. Then, right
after, thread B also wants to go back to user mode, and since it has
higher priority than thread A it will preempt thread A and start running
instead? And this is just for the case where a thread returns to user
mode, for threads already in user mode normal scheduling will occur?

-- 
Erik Wikström





More information about the Bugs mailing list