[lkml]   [2012]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 2/4] mm: make consistent use of PG_slab flag
On 07/05/2012 10:47 PM, Christoph Lameter wrote:
> On Tue, 3 Jul 2012, Jiang Liu wrote:
>> PG_slabobject: mark whether a (compound) page hosts SLUB/SLOB objects.
> Any subsystem may allocate a compound page to store metadata.
> The compound pages used by SLOB and SLUB are not managed in any way but
> the calls to kfree and kmalloc are converted to calls to the page
> allocator. There is no "management" by the slab allocators for these
> cases and its inaccurate to say that these are SLUB/SLOB objects since the
> allocators never deal with these objects.
Hi Chris,
I think there's a little difference with SLUB and SLOB for compound page.
For SLOB, it relies on the page allocator to allocate compound page to fulfill
request bigger than one page. For SLUB, it relies on the page allocator if the
request is bigger than two pages. So SLUB may allocate a 2-pages compound page
to host SLUB managed objects.
My proposal may be summarized as below:
1) PG_slab flag marks a memory object is allocated from slab allocator.
2) PG_slabobject marks a (compound) page hosts SLUB/SLOB managed objects.
3) Only set PG_slab/PG_slabobject on the head page of compound pages.
4) For SLAB, PG_slabobject is redundant and so not used.

A summary of proposed usage of PG_slab(S) and PG_slabobject(O) with
SLAB/SLUB/SLOB allocators as below:
1page S S,O S,O
2page S S,O S
>=4page S S S


 \ /
  Last update: 2012-07-05 19:21    [W:0.058 / U:13.788 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site