Re: RSDL-mm 0.28

[William Lee Irwin III <wli@holomorphy.com>]

On Sun, 11 Mar 2007 13:28:22 +1100 "Con Kolivas" <kernel@kolivas.org> wrote:
>> Well... are you advocating we change sched_yield semantics to a
>> gentler form?

On Sat, Mar 10, 2007 at 07:16:14PM -0800, Andrew Morton wrote:
> From a practical POV: our present yield() behaviour is so truly awful that
> it's basically always a bug to use it.  This probably isn't a good thing.
> So yes, I do think that we should have a rethink and try to come up with
> behaviour which is more in accord with what application developers expect
> yield() to do.

ISTR that apps varied wrt. their expectations for yield(). Some,
particularly those using it to implement multi-tiered userspace locks,
really did expect to go all the way to the back of the queue. (Rumor has
it that realtime apps break otherwise.) Others wanted a kinder, gentler,
"mistress, please hit me, but not too hard" opportunity to let someone
else have a little cpu time, particularly when userspace is spinning in
some sort of busywait. In both scenarios something very much against
the latest trends of Linux kernel politics is done by userspace.


On Sat, Mar 10, 2007 at 07:16:14PM -0800, Andrew Morton wrote:
> otoh,
> a) we should have done this five years ago.  Instead, we've spent that
>    time training userspace programmers to not use yield(), so perhaps
>    there's little to be gained in changing it now.
> b) if we _were_ to change yield(), people would use it more, and their
>    applications would of course suck bigtime when run on earlier 2.6
>    kernels.
> Bottom line: we've had a _lot_ of problems with the new yield() semantics. 
> We effectively broke back-compatibility by changing its behaviour a lot,
> and we can't really turn around and blame application developers for that.

My dumb idea would be to break out new syscall. One for the kinder,
gentler version, one for the serious version. Or otherwise pass an
argument indicating the expected behavior. Then a dumb app can be
LD_PRELOAD'd into calling whatever makes it run fastest.


-- wli