linux-kernel - Re: [patch 21/21] slab defrag: Obsolete SLAB

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]

Message-ID: <Pine.LNX.4.64.0805151002420.18354@schroedinger.engr.sgi.com>
Date:	Thu, 15 May 2008 10:05:35 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
cc:	Andi Kleen <andi@...stfloor.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Rik van Riel <riel@...hat.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>, mpm@...enic.com,
	Matthew Wilcox <matthew@....cx>
Subject: Re: [patch 21/21] slab defrag: Obsolete SLAB

On Thu, 15 May 2008, Zhang, Yanmin wrote:

> > It can thrash cachelines if objects from the same slab page are freed 
> > simultaneously on multiple processors. That occurred in the hackbench 
> > regression that we addressed with the dynamic configuration of slab sizes.
> hackbench regression is because of slow allocation instead of slow freeing.
> With ÿÿdynamic configuration of slab sizes, fast allocation becomes 97% (the bad
> one is 68%), but fast free is always 8~9% with/without the patch.

Thanks for using the slab statistics. I wish I had these numbers for the 
TPC benchmark. That would allow us to understand what is going on while it 
is running.

The frees in the hackbench were slow because partial list updates occurred 
to frequently. The first fix was to let slab sit longer on the partial 
list. The other was the increase of the slab sizes which also increases 
the per cpu slab size and therefore the objects allocatable without a 
round trip to the page allocator. Freeing to a per cpu slab never requires 
partial list updates. So the frees also benefitted from the larger slab 
sizes. But the effect shows up in the count of partial list updates not in 
the fast/free collumn.