Re: sched_yield: delete sysctl_sched_compat_yield

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> > > I was just talking about the default because I didn't know the 
> > > reason for the way it was set -- now that I do, we should talk 
> > > about trying to improve the actual code so we don't need 2 
> > > defaults.
> >
> > I've got the patch below queued up: it uses the more agressive yield 
> > implementation for SCHED_BATCH tasks. SCHED_BATCH is a natural 
> > differentiator, it's a "I dont care about latency, it's all about 
> > throughput for me" signal from the application.
> 
> First and foremost, do you realize that I'm talking about existing 
> userspace working well on future kernels right? (ie. backwards 
> compatibility).

given how poorly sched_yield() is/was defined the only "compatible" 
solution would be to go back to the old yield code. (And note that you 
are rehashing arguments that were covered on lkml months ago already.)

> > But first and foremost, do you realize that there will be no easy 
> > solutions to this topic, that it's not just about 'flipping a 
> > default'?
> 
> Of course ;) I already answered that in the email that you're replying 
> to:
> 
> > > I was just talking about the default because I didn't know the 
> > > reason for the way it was set -- now that I do, we should talk 
> > > about trying to improve the actual code so we don't need 2 
> > > defaults.

well, in case you were wondering why i was a bit pointy about this, this 
topic of yield has been covered on lkml quite extensively a couple of 
months ago. I assumed you knew about that already, but perhaps not?

> Anyway, I'd hope it can actually be improved and even the sysctl 
> removed completely.

i think the sanest long-term solution is to strongly discourage the use 
of SCHED_OTHER::yield, because there's just no sane definition for yield 
that apps could rely upon. (well Linus suggested a pretty sane 
definition but that would necessiate the burdening of the scheduler 
fastpath - we dont want to do that.) New ideas are welcome of course.

[ also, actual technical feedback on the SCHED_BATCH patch i sent (which
  was the only "forward looking" moment in this thread so far ;-) would
  be nice too. ]

	Ingo
--
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/