linux-kernel - Re: [tip:sched/urgent] sched: Fix select_idle_sibling() regression in selecting an idle SMT sibling

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:	Fri, 23 Dec 2011 10:43:34 -0800
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	"Shi, Alex" <alex.shi@...el.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"efault@....de" <efault@....de>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"Chen, Tim C" <tim.c.chen@...el.com>,
	"Huang, Ying" <ying.huang@...el.com>
Subject: Re: [tip:sched/urgent] sched: Fix select_idle_sibling() regression
 in selecting an idle SMT sibling

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/