From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [Bug #15713] hackbench regression due to commit 9dfc6e68bfe6e Date: Mon, 26 Apr 2010 12:02:38 +0200 Message-ID: <4BD564BE.6020700@kernel.org> References: <4BD086D0.9090309@cs.helsinki.fi> <1272265147.2078.648.camel@ymzhang.sh.intel.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Pekka Enberg Cc: "Zhang, Yanmin" , Christoph Lameter , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Maciej Rutecki , Alex Shi , tim.c.chen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org Hello, On 04/26/2010 09:22 AM, Pekka Enberg wrote: > On Mon, Apr 26, 2010 at 9:59 AM, Zhang, Yanmin > wrote: >>> I haven't been able to reproduce this either on my Core 2 machine. >> Mostly, the regression exists on Nehalem machines. I suspect it's related to >> hyper-threading machine. > > OK, so does anyone know why hyper-threading would change things for > the per-CPU allocator? My wild speculation is that previously the cpu_slub structures of two neighboring threads ended up on the same cacheline by accident thanks to the back to back allocation. W/ the percpu allocator, this no longer would happen as the allocator groups percpu data together per-cpu. Thanks. -- tejun