Re: sched_yield() on 2.6.25

[Helge Hafting]

Leon Woestenberg wrote:
[...]
> That's not the definition of sched_yield(). See the earlier emails,
> and the quote above.
>
> As the code after sched_yield() has to be executed the thread will be
> rescheduled soon (or even immediately) anyway.
>
> The users not understanding the limited scope where sched_yield()
> behaves deterministicly, seem to think that _yield() will yield() AND
> lower the thread's dynamic priority for SCHED_OTHER. Is downgrading
> the dynamic priority a behavioral option?
>   
That can be done of course, but that too will cause breakage.
Consider a multithreaded app mistakenly relying on sched_yield.

Priority downgrading might work really well as long as this app runs alone,
the yielding thread stops and the others progress, so sched_yield works
for "userspace locking". And it works so well, the app uses it a lot.

Then someone recompiles the distro or runs some other kinds of cpu hogs
that drives the load well above 1. Users expect the apps to run a little
slower because of this. But a load of 5 still ought to give you 1/5
of the cpu - and with today's CPU's that might still be better than
a 5-year old machine. Interactive software should almost not notice,
as it don't use the cpu that much anyway - and it gets priority over
cpu hogs when it occationally needs to do something.

But now this multithreaded app practically
stops because it yields a lot - an everytime it lowers its priority
below not only its own other threads, but below the various
cpu hogs as well. (Compilers gets dynamic boosts too, as they
wait a little for the disk now and then. A parallel compile still
keeps the total load high.)

I remember seeing openoffice taking 5min to start some years ago,
with a compile going on. Of course there were other problems
like swapping and a smaller computer, but other apps were merely slow,
not that glacial.
> On the other hand, I don't think anything should encourage the use of
> sched_yield() outside of the rare SCHED_FIFO/RR case.
>   
Exactly. There seems to be no way to make sched_yield work "as expected"
for all the ways it is abused, so better use something else.

Helge Hafting




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/