Messages in this thread | | | Date | Thu, 29 Nov 2007 18:51:44 -0800 | From | Arjan van de Ven <> | Subject | Re: sched_yield: delete sysctl_sched_compat_yield |
| |
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.
> > > > 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!
-- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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/
| |