linux-kernel - Re: SLUB defrag pull request?

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: <49009575.60004@cosmosbay.com>
Date:	Thu, 23 Oct 2008 17:17:09 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Miklos Szeredi <miklos@...redi.hu>, nickpiggin@...oo.com.au,
	hugh@...itas.com, linux-mm@...ck.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: SLUB defrag pull request?

Christoph Lameter a écrit :
> On Thu, 23 Oct 2008, Pekka Enberg wrote:
> 
>>> The problem looks like its freeing objects on a different processor that
>>> where it was used last. With the pointer array it is only necessary 
>>> to touch
>>> the objects that contain the arrays.
>>
>> Interesting. SLAB gets away with this because of per-cpu caches or
>> because it uses the bufctls instead of a freelist?
> 
> Exactly. Slab adds a special management structure to each slab page that 
> contains the freelist and other stuff. Freeing first occurs to a per cpu 
> queue that contains an array of pointers. Then later the objects are 
> moved from the pointer array into the management structure for the slab.
> 
> What we could do for SLUB is to generate a linked list of pointer arrays 
> in the free objects of a slab page. If all objects are allocated then no 
> pointer array is needed. The first object freed would become the first 
> pointer array. If that is found to be exhausted then the object 
> currently being freed is becoming the next pointer array and we put a 
> link to the old one into the object as well.
> 

This idea is very nice, especially considering that many objects are freed
by RCU, and their rcu_head (which is hot at kfree() time), might be far
away the linked list anchor actually used in SLUB.

At alloc time, I remember I added a prefetchw() call in SLAB in __cache_alloc(),
this could explain some differences between SLUB and SLAB too, since SLAB
gives a hint to processor to warm its cache.




--
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/