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 16:33:33 +0200 Message-ID: <4BD5A43D.2060009@kernel.org> References: <4BD086D0.9090309@cs.helsinki.fi> <1272265147.2078.648.camel@ymzhang.sh.intel.com> <4BD564BE.6020700@kernel.org> <4BD570A8.90304@kernel.org> 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 J 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, npiggin-l3A5Bk7waGM@public.gmane.org, rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org Hello, Pekka. On 04/26/2010 04:17 PM, Pekka J Enberg wrote: > Even if the cacheline is dirtied like in the struct kmem_cache_cpu case? If my hypothesis is the case, I don't think dirtying or not would matter. It's about two cpus sharing a cache line which usually is a bad idea but in this case happens to be a good idea because the two cpus sit on the same cache. > If that's the case, don't we want the per-CPU allocator to support back > to back allocation for cores that are in the same package? I think it's probably gonna be an over-engineering effort. W/ percpu allocator the rest of the cacheline would likely be occupied by another percpu item for the cpu, so it's not really wasted. It's just used differently. It would be good if we have a way to better pack small hot ones (for the same cpu) into the same cachelines but I don't think it would be wise to interleave stuff from different cpus. It's not like there's only single way to save a cacheline after all. Thanks. -- tejun