Re: [PATCH v7 0/8] Tunable sched_mc_power_savings=n

[Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>]

* Mike Galbraith <efault@gmx.de> [2009-01-04 16:00:00]:

> 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@gmx.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.

Hi Mike,

Thanks for the detailed test report.

I am new to sysbench.  I just started few OLTP runs with pgsql. In
your graph you are plotting and comparing read/write-per-sec and not
transactions-per-sec.  Both the parameter vary in a similar manner.
Can you please let me know some background on using the
read/write-per-sec result for comparison.

I assume you have run the above tests on Q6600 box that has single
quad core package that consist of two dual core CPUs.  Can you please
let me know the sched_domain tree that was build by hacking
mc_capable().  The effect of sched_mc={1,2} depends on the
sched groups that was build and their flags.

As you have mentioned in your data, sched_mc=2 helps recover some
performance mainly because of NEWIDLE balance.  

You have mentioned clients in the x-axis of the graph, what is their
relation to the number of threads?  

Please feel free to point me to any previous discussion on sysbench
where the above questions have been discussed.

Thanks,
Vaidy