public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Paul Mundt <lethal@linux-sh.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	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 07:43:02 +0300	[thread overview]
Message-ID: <4834F9D6.7080706@cs.helsinki.fi> (raw)
In-Reply-To: <20080522043410.GA4050@linux-sh.org>

Hi Paul,

Paul Mundt wrote:
> 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.

Well, we should really be calling ksize() in the nommu case and although 
Matt and Christoph don't seem to agree with me here, I'd much rather 
have *all* allocators set PageSlab for all the pages they return (yes, 
including pass-through ones) to get us back where we were with SLAB. We 
currently don't have any means to see whether an arbitrary page is part 
of the slab or not and I'd argue that's PageSlab is an established API 
(that makes sense).

Furthermore, if ksize() in SLOB doesn't work for kmem_cache_alloc() 
pages, I think it should be fixed as well.

			Pekka

  reply	other threads:[~2008-05-22  4:45 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
2008-05-22  4:43           ` Pekka Enberg [this message]
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=4834F9D6.7080706@cs.helsinki.fi \
    --to=penberg@cs.helsinki.fi \
    --cc=clameter@sgi.com \
    --cc=dhowells@redhat.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox