lkml.org 
[lkml]   [2007]   [Dec]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sched_yield: delete sysctl_sched_compat_yield

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

> On Friday 30 November 2007 21:08, Ingo Molnar wrote:
> > * Nick Piggin <nickpiggin@yahoo.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


\
 
 \ /
  Last update: 2007-12-03 09:49    [W:1.511 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site