All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <clameter@sgi.com>,
	linux-kernel@vger.kernel.org, mpm@selenic.com,
	dhowells@redhat.com
Subject: Re: [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize()
Date: Thu, 22 May 2008 13:34:10 +0900	[thread overview]
Message-ID: <20080522043410.GA4050@linux-sh.org> (raw)
In-Reply-To: <4834F4DC.3040009@cs.helsinki.fi>

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.

  reply	other threads:[~2008-05-22  4:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-21 18:25 [RFC/PATCH 1/3] SLAB: Add PageSlab checking to ksize() Pekka J Enberg
2008-05-21 23:45 ` Paul Mundt
2008-05-22  4:13   ` Pekka Enberg
2008-05-22  4:17     ` Christoph Lameter
2008-05-22  4:21       ` Pekka Enberg
2008-05-22  4:34         ` Paul Mundt [this message]
2008-05-22  4:43           ` Pekka Enberg
2008-05-22  4:55             ` Paul Mundt
2008-05-22 15:01             ` Matt Mackall
2008-05-22 16:13               ` Pekka Enberg
2008-05-22 16:51                 ` Christoph Lameter
2008-05-22 18:31                 ` Matt Mackall
2008-05-23 14:23                 ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080522043410.GA4050@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=clameter@sgi.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    --cc=penberg@cs.helsinki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.