Messages in this thread | | | Date | Thu, 12 Jun 2008 10:09:16 +0200 | From | Helge Hafting <> | Subject | Re: sched_yield() on 2.6.25 |
| |
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
| |