linux-kernel - Re: [PATCH v7 0/8] Tunable sched_mc_power

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:	Sun, 04 Jan 2009 16:00:00 +0100
From:	Mike Galbraith <efault@....de>
To:	svaidy@...ux.vnet.ibm.com
Cc:	Ingo Molnar <mingo@...e.hu>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v7 0/8] Tunable sched_mc_power_savings=n

On Sat, 2009-01-03 at 12:22 +0100, Mike Galbraith wrote:
> On Sat, 2009-01-03 at 15:46 +0530, Vaidyanathan Srinivasan wrote:
> > * Mike Galbraith <efault@....de> [2009-01-03 08:29:25]:
> > 
> > > On Fri, 2009-01-02 at 23:16 +0100, Ingo Molnar wrote:
> > > 
> > > > Mike, would you be interesting in having a look at sched_mc=2 as a 
> > > > kernel-wide default - and give it your blessing if you find it to be a net 
> > > > improvement for the various performance and interactivity tests you do?
> > > 
> > > Sure.
> > 
> > Thanks Mike and Ingo.  I will be glad to help with test and benchmarks
> > on the platforms that I have access.
> > 
> > I am presently working on sysbench.
> 
> The testing I can do is rather severely limited since I have only one
> Q6600.  I butchered mc_capable() to use what I can though, ie see if
> SD_BALANCE_NEWIDLE still harms tbench and mysql+oltp.  I think that's
> about all I can do on my wee box.

I do not see any difference for tbench, results are within jitter.  I do
for mysql+oltp, and the test results are fairly strange.

If you take a peek at the attached chart: the 2.6.26.8 data is with
scalability backports/fixes.  That's where our 29-to-be should be.
Domain tunings in this kernel are identical to 28/29 stock as well.

Note that there is no knee at 8 clients.  If I turn SD_BALANCE_NEWIDLE
on in 26+backports, peak drops a tad, and that knee re-appears, just as
before we turned the thing off.  Throughput after the knee also drops a
tad, nearly to the point where tip+sched_mc=2 now _comes up to_, and it
definitely is SD_BALANCE_NEWIDLE making the difference.  IOW, what used
to be a loser, and still is a loser in 26+fixes, is now a winner in tip
after the knee which should not be there.  Seems something else has
changed, re-introducing the knee, and cutting throughput a tad.

(The hefty difference at the very end I knew about.  SD_BALANCE_NEWIDLE
helps considerably when mysql is very thoroughly jammed up on itself)

When I look at that chart, it looks almost like SD_BALANCE_NEWIDLE is
partially offsetting some other problem.

I haven't done any interactivity testing yet.

	-Mike

Download attachment "zzz.jpg" of type "image/jpeg" (75980 bytes)