Message-Id: <200712032202.37975.nickpiggin@yahoo.com.au>
Date:	Mon, 3 Dec 2007 22:02:37 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: sched_yield: delete sysctl_sched_compat_yield

On Monday 03 December 2007 21:33, Ingo Molnar wrote:
> * Nick Piggin <nickpiggin@...oo.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.

While it is technically allowed to do anything with SCHED_OTHER class,
putting the thread to the back of the runnable tasks, or at least having
it give up _some_ priority (like the old scheduler) is less surprising
than having it do _nothing_.

I mean, if firefox really works best if sched_yield does nothing, it
surely shouldn't be calling it at all (nothing to do with it being open
source or not).

Wheras JVMs (eg. that have garbage collectors call yield), presumably
get quite a lot of tuning, and that was probably done with the less
surprising (and more common) sched_yield behaviour.


> (And note that you 
> are rehashing arguments that were covered on lkml months ago already.)

I'm just wondering whether the outcome was the right one.


> > > 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?

I did, but I haven't always followed the scheduler discussions closely
recently. I was surprised to find it hasn't changed much.

I appreciate you can never do exactly the right thing for everyone and
you can't (and don't want, by definition) to make behaviour exactly the
same.

Clearly the current default is far less aggressive (almost noop), and the
compat behaviour is probably more aggressive in most cases than the old
scheduler. I would have thought looking for a middle ground might be a
good idea.

Or just ignore firefox and get them to fix it, if the occasional stalls
are during really high scheduler stressing workloads (do you have a pointer
to that thread, btw?).


> > 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.

sched_yield is defined to put the calling task at the end of the queue for
the given priority level as you know (ie. at the end of all other priority
0 tasks, for SCHED_OTHER).

So, while SCHED_OTHER technically allows _any_ task to be picked, I think
it would be least surprising to have the calling task go to the end of the
queue, rather than not doing very much at all...


> [ 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. ]

I dislike a wholesale change in behaviour like that. Especially when it
is changing behaviour of yield among SCHED_BATCH tasks versus yield among
SCHED_OTHER tasks.

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

Powered by blists - more mailing lists