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
