[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080522043410.GA4050@linux-sh.org>
Date: Thu, 22 May 2008 13:34:10 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Pekka Enberg <penberg@...helsinki.fi>
Cc: Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org,
mpm@...enic.com, dhowells@...hat.com
Subject: Re: [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize()
On Thu, May 22, 2008 at 07:21:48AM +0300, Pekka Enberg wrote:
> Christoph Lameter wrote:
> >>That's probably due to the fact that we use PageSlab for all pages with
> >>SLUB
> >>and for bigblock pages in SLOB with this patch. Christoph, Matt, any
> >>suggestions how to fix the PageSlab check in nommu btw?
> >
> >I already posted a patch and commented numerous times. What else needs
> >to be said? SLUB only uses PageSlab for kmalloc <=4kb.
>
> (I missed your patch, btw.)
>
> For SLOB, we will never use ksize() as it doesn't set PageSlab. Is that
> not a problem?
>
That means that kobjsize() will hand back PAGE_SIZE for non-compound
pages, which is what it's presently doing anyways. In the case of SLOB
bigblock pages allocated on pass-through to the page allocator, these are
compound pages anyways, so compound_page() should do the right thing
there? That only handles the kmalloc() path though, and not the
kmem_cache_alloc() cases.
Shouldn't SLOB's PageSlab usage should mimic that of SLUB in this case
instead? PG_slab doesn't buy us much if we can already sort out the size
through compound_order(), it's the kmem_cache_alloc() and <= PAGE_SIZE
kmalloc()'s where __GFP_COMP isn't true and where PG_slab should be set.
--
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/
Powered by blists - more mailing lists