linux-kernel - Re: sched_yield: delete sysctl_sched_compat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071203103326.GD30050@elte.hu>
Date:	Mon, 3 Dec 2007 11:33:26 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Nick Piggin <nickpiggin@...oo.com.au>
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

* 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. (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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/