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: pagesize SLAB SLUB SLOB 1page S S,O S,O 2page S S,O S >=4page S S S Thanks! Gerry -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>