linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
From: Christoph Lameter <clameter@engr.sgi.com>
To: clameter@engr.sgi.com
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH] SLUB The unqueued slab allocator V3
Date: Wed, 28 Feb 2007 14:00:22 -0800 (PST)
Date: Wed, 28 Feb 2007 11:20:44 -0800 (PST)	[thread overview]
Message-ID: <20070228.140022.74750199.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0702281120110.27828@schroedinger.engr.sgi.com>

> V2->V3
> - Debugging and diagnostic support. This is runtime enabled and not compile
>   time enabled. Runtime debugging can be controlled via kernel boot options
>   on an individual slab cache basis or globally.
> - Slab Trace support (For individual slab caches).
> - Resiliency support: If basic sanity checks are enabled (via F f.e.)
>   (boot option) then SLUB will do the best to perform diagnostics and
>   then continue (i.e. mark corrupted objects as used).
> - Fix up numerous issues including clash of SLUBs use of page
>   flags with i386 arch use for pmd and pgds (which are managed
>   as slab caches, sigh).
> - Dynamic per CPU array sizing.
> - Explain SLUB slabcache flags

V3 doesn't boot successfully on sparc64, sorry I don't have the
ability to track this down at the moment since it resets the
machine right as the video device is initialized and after diffing
V2 to V3 there is way too much stuff changing for me to try and
"bisect" between V2 to V3 to find the guilty sub-change.

Maybe if you managed your individual changes in GIT or similar
this could be debugged very quickly. :-)

Meanwhile I noticed that your alignment algorithm is different
than SLAB's.  And I think this is important for the page table
SLABs that some platforms use.

No matter what flags are specified, SLAB gives at least the
passed in alignment specified in kmem_cache_create().  That
logic in slab is here:

	/* 3) caller mandated alignment */
	if (ralign < align) {
		ralign = align;
	}

Whereas SLUB uses the CPU cacheline size when the MUSTALIGN
flag is set.  Architectures do things like:

	pgtable_cache = kmem_cache_create("pgtable_cache",
					  PAGE_SIZE, PAGE_SIZE,
					  SLAB_HWCACHE_ALIGN |
					  SLAB_MUST_HWCACHE_ALIGN,
					  zero_ctor,
					  NULL);

to get a PAGE_SIZE aligned slab, SLUB doesn't give the same
behavior SLAB does in this case.

Arguably SLAB_HWCACHE_ALIGN and SLAB_MUST_HWCACHE_ALIGN should
not be set here, but SLUBs change in semantics in this area
could cause similar grief in other areas, an audit is probably
in order.

The above example was from sparc64, but x86 does the same thing
as probably do other platforms which use SLAB for pagetables.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-02-28 22:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-28 19:20 [PATCH] SLUB The unqueued slab allocator V3 Christoph Lameter
2007-02-28 22:00 ` David Miller, Christoph Lameter [this message]
2007-02-28 22:17   ` David Miller, David Miller
2007-03-01  1:06   ` Christoph Lameter
2007-03-01  1:48     ` David Miller, Christoph Lameter

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=20070228.140022.74750199.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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;
as well as URLs for NNTP newsgroup(s).