linux-kernel - Re: hackbench regression due to commit 9dfc6e68bfe6e

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:	Wed, 07 Apr 2010 08:58:33 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Tejun Heo <tj@...nel.org>, Pekka Enberg <penberg@...helsinki.fi>,
	alex.shi@...el.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Ma, Ling" <ling.ma@...el.com>,
	"Chen, Tim C" <tim.c.chen@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: hackbench regression due to commit 9dfc6e68bfe6e

On Tue, 2010-04-06 at 10:41 -0500, Christoph Lameter wrote:
> On Tue, 6 Apr 2010, Zhang, Yanmin wrote:
> 
> > Thanks. I tried 2 and 4 times and didn't see much improvement.
> > I checked /proc/vamallocinfo and it doesn't have item of pcpu_get_vm_areas
> > when I use 4 times of PERCPU_DYNAMIC_RESERVE.
> 
> > I used perf to collect dtlb misses and LLC misses. dtlb miss data is not
> > stable. Sometimes, we have a bigger dtlb miss, but get a better result.
> >
> > LLC misses data are more stable. Only LLC-load-misses is the clear sign now.
> > LLC-store-misses has no big difference.
> 
> LLC-load-miss is exactly what condition?
I don't know. I just said it's a clear sign. Otherwise, there is no clear sign.
The function statistics collected by perf with event llc-load-misses are very
scattered.

> 
> The cacheline environment in the hotpath should only include the following
> cache lines (without debugging and counters):
> 
> 1. The first cacheline from the kmem_cache structure
> 
> (This is different from the sitation before the 2.6.34 changes. Earlier
> some critical values (object length etc) where available
> from the kmem_cache_cpu structure.  The cacheline containing the percpu
> structure array was needed to determome the kmem_cache_cpu address!)
> 
> 2. The first cacheline from kmem_cache_cpu
> 
> 3. The first cacheline of the data object (free pointer)
> 
> And in case of a kfree/ kmem_cache_free:
> 
> 4. Cacheline that contains the page struct of the page the object resides
> in.
I agree with your analysis, but we still have no answer.

> 
> Can you post the .config you are using and the bootup messages?
> 

Pls. see the 2 attachment.

CONFIG_SLUB_STATS has no big impact on results.

Yanmin


View attachment "2.6.34-rc3-slubtj.dmesg" of type "text/plain" (57917 bytes)

View attachment "2.6.34-rc3_config" of type "text/x-mpsub" (60214 bytes)