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 for Android: free password hash cracker in your pocket

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

Message-ID: <20071203084557.GA13156@elte.hu>
Date:	Mon, 3 Dec 2007 09:45:57 +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:

> On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > * Nick Piggin <nickpiggin@...oo.com.au> wrote:
> > > Haven't we been asking JVMs to use futexes or posix locking for years
> > > and years now? [...]
> >
> > i'm curious, with what JVM was it tested and where's the source so i 
> > can fix their locking for them? Can the problem be reproduced with:
> 
> Sure, but why shouldn't the compat behaviour be the default, and the 
> sysctl go away?
> 
> It makes older JVMs work better, it is slightly closer to the old 
> behaviour, and it is arguably a less surprising result.

as far as desktop apps such as firefox goes, the exact opposite is true. 
We had two choices basically: either a "more agressive" yield than 
before or a "less agressive" yield. Desktop apps were reported to hurt 
from a "more agressive" yield (firefox for example gets some pretty bad 
delays), so we defaulted to the less agressive method. (and we defaulted 
to that in v2.6.23 already) Really, in this sense volanomark is another 
test like dbench - we care about it but not unconditionally and in this 
case it's a really silly API use that is at the center of the problem. 
Talking about the default alone will not bring us forward, but we can 
certainly add helpers to identify SCHED_OTHER::yield tasks - a once per 
bootup warning perhaps?

	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/