* Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
