linux-kernel - Re: [git pull] scheduler fixes

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]

Date:	Sat, 17 Jan 2009 17:37:12 +0100
From:	Mike Galbraith <efault@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>, Kevin Shanahan <kmshanah@...b.org.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	a.p.zijlstra@...llo.nl, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] scheduler fixes

On Sat, 2009-01-17 at 17:25 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@....de> wrote:
> 
> > On Sat, 2009-01-17 at 17:01 +0100, Ingo Molnar wrote:
> > > * Mike Galbraith <efault@....de> wrote:
> > > 
> > > > On Sat, 2009-01-17 at 04:43 -0800, Andrew Morton wrote:
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12465 just popped up - another
> > > > > scheduler regression.  It has been bisected.
> > > > 
> > > > Seems pretty clear.  I'd suggest reverting it.
> > > 
> > > We can revert it (and will revert it if no solution is found), but i'd 
> > > also like to understand why it happens, because that kind of 
> > > regression from this change is unexpected - we might be hiding some 
> > > bug that could pop up under less debuggable circumstances, so we need 
> > > to understand it while we have a chance.
> > 
> > Agree.  However, with the sched_mc stuff, mysql+oltp now does better 
> > with NEWIDLE on than off as well, as does an nfs kbuild.
> 
> Didnt you come up with the verdict that sched_mc=2 is not a win - or has 
> that changed? If we should change the defaults then please send a 
> re-tuning patch against the latest code.

sched_mc=2 was better than sched_mc=1.  The other balancing changes put
a dent in mysql+oltp peak and immediately after peak.  Setting
sched_mc=2 brought back the loss that was otherwise there all the way
through the curve back to 28 level, so with sched_mc=2, there was only
the slight loss of peak, and larger loss of post-peak.

> Still, the ping delays of multiple seconds are completely unacceptable and 
> need to be understood, or these will come back and might bite us in a lot 
> less fortunate place. NEWIDLE and WAKE_BALANCE has micro-effects on 
> latencies - anything in the user-visible range is highly anomalous at 
> these low load levels.
> 
> 	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/