Messages in this thread | | | From | Nick Piggin <> | Subject | Re: sched_yield: delete sysctl_sched_compat_yield | Date | Fri, 30 Nov 2007 14:02:36 +1100 |
| |
On Friday 30 November 2007 13:51, Arjan van de Ven wrote: > On Fri, 30 Nov 2007 13:46:22 +1100 > > Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > > Todays kernel has a different behavior somewhat (and before people > > > scream "regression"; sched_yield() behavior isn't really specified > > > and doesn't make any sense at all, whatever you get is what you > > > get.... it's pretty much an insane defacto behavior that is > > > incredibly tied to which decisions the scheduler makes how, and no > > > app can depend on that > > > > It is a performance regression. Is there any reason *not* to use the > > "compat" yield by default? As you say, for SCHED_OTHER tasks, yield > > can do almost anything. We may as well do something that isn't a > > regression.. > > it just makes OTHER tests/benchmarks regress.... this is one of those > things where you just can't win.
OK, which ones? Because java is slightly important...
> > > in any way. In fact, I've proposed to make sched_yield() just do an > > > msleep(1)... that'd be closer to what sched_yield is supposed to do > > > standard wise than any of the current behaviors .... ;_ > > > > What makes you say that? IIRC of all the things that sched_yeild can > > do, it is not allowed to block. So this is about the only thing that > > will break the standard... > > sched_yield OF COURSE can block.. it's a schedule call after all!
In unix, blocking ~= removed from runqueue, no?
OF COURSE it is allowed to cooperatively schedule another task, but I don't see why you think it should so obviously be allowed to block / sleep.
It breaks the basically only invariant of sched_yeild in that the task will no longer run when there is nothing else running. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |