Re: [tip:sched/urgent] sched: Fix select_idle_sibling() regressionin selecting an idle SMT sibling

[Suresh Siddha]

On Wed, 2011-12-21 at 18:16 -0800, Shi, Alex wrote:
> On Thu, 2011-12-22 at 10:03 +0800, Siddha, Suresh B wrote:
> > On Wed, 2011-12-21 at 17:31 -0800, Shi, Alex wrote:
> > > This patch partly fixed a performance regression that triggered by
> > > 4dcfe1025b513c2c, but issue still exists.
> > 
> > So how much was the regression caused by the commit 4dcfe1025b513c2c and
> > how much did we recover with this fix I posted. If we are talking about
> > the regression caused by this single commit 4dcfe1025b513c2c, then I
> > don't know of any other related fixes other than the recent fix we
> > pushed upstream (ab2789213d224202237292d78aaa0c386c7b28b2).
> 
> A little complex for the whole thing. 
> on 4 sockets EX machine, 3~5% hackbench thread regression due to 4dcfe
> can be recovered by ab2789. 
> 
> But on 2 sockets SNB machine, 1024 clients loop netperf TCP-RR has about
> 9% regression. and your patch seem recover 2~3%. 
> 
> And on a 2 sockets nhm, one of our private benchmark was impact much 20
> +% regression. that benchmark just run 4 process, each of process open a
> thread, and the thread tasks is to locate randomly pages and than read
> from 4 times/write 1 time data into a page.  The ab2789 commit seems no
> help our benchmark. 

Ok. Can you please try couple of experiments with two kernels? Two
kernels being the base kernel (prior to 4dcfe1025b513c2c) and the second
kernel with the commit ab2789213d224202237292d78aaa0c386c7b28b2.

One experiment with p-states turned off and the second experiment with
c-states turned off.

I suspect mostly deeper core c-states might be contributing to the
behavior that you are seeing.

thanks,
suresh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/