Re: Scheduler Cleanup

[Davide Libenzi]

On Thu, 6 Dec 2001, Ingo Molnar wrote:

>
> On Wed, 5 Dec 2001, Mike Kravetz wrote:
>
> > One thing to note is that possible acquisition of the runqueue lock
> > was reintroduced in sys_sched_yield().  From looking at the code, it
> > seems the purpose was to ?add fairness? in the case of multiple
> > yielders.  Is that correct Ingo?
>
> yes, it's to add fairness. You might remember that i did this
> sched_yield() optimization originally to help Volanomark performance. But
> it turned out that it's very unfair not to move yielded processes to the
> end of the runqueue - it might even cause livelocks in user-space
> spinlocks which use sched_yield(). (since the POLICY_YIELD bit prevents
> the process from running only *once*, so it will handle a two-process lock
> situation right, but if multiple processes are racing for the lock then
> they might exclude the real owner of the spinlock for a *long* time.)
>
> (plus the change also broke sched_yield() for RT-FIFO processes.)

What about decreasing counter by 1 for each sched_yield() call ?
Is this case we achieve ( expecially with the counter decay patch ) a
correct task recycling w/out lock acquiring inside the system call.

> while i see the point that the multiqueue scheduler improves performance
> visibly, i'm quite sure you could get an *order of magnitude* faster if
> the basic threading model (and any possible underlying mechanizm, such as
> LinuxThreads) was fixed. The current Linux scheduler just magnifies these
> userspace design problems. LinuxThreads was done when there werent many
> good mechanizms within the kernel to help threading. Things have changed
> by today - but if something still cannot be done cleanly and efficiently
> (such as userspace spinlocks or semaphores) then please let us know so we
> can fix things, instead of trying to work around the symptoms. But this is
> just a suggestion.

Ingo, you've to admit that having separate run queue with separate locks
is just more than a benchmark fix, it's matter of sane design.

- Davide