public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chinner <dgc@sgi.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: mpm@selenic.com, Marcelo Tosatti <marcelo@kvack.org>,
	linux-kernel@vger.kernel.org,
	Nick Piggin <nickpiggin@yahoo.com.au>, Andi Kleen <ak@suse.de>,
	Manfred Spraul <manfred@colorfullife.com>,
	Dave Chinner <dgc@sgi.com>
Subject: Re: [MODSLAB 0/7] A modular slab allocator V1
Date: Wed, 16 Aug 2006 18:12:08 +1000	[thread overview]
Message-ID: <20060816081208.GL51703024@melbourne.sgi.com> (raw)
In-Reply-To: <20060816022238.13379.24081.sendpatchset@schroedinger.engr.sgi.com>

On Tue, Aug 15, 2006 at 07:22:38PM -0700, Christoph Lameter wrote:
> Some of the other issues in the slab layer are also addressed here:
> 
> 1. shrink_slab takes a function to move object. Using that
>    function slabs can be defragmented to ease slab reclaim.
> 
> 2. Bootstrap occurs through dynamic slab creation.
> 
> 3. New slabs that are created can be merged into the kmalloc array
>    if it is detected that they match. This decreases the number of caches
>    and benefits cache use.

While this will be good for reducing fragmentation, one important
thing is needed here for tracking down leaks and slab corruptions -
the ability to split the caches back out into individual slabs.
Maybe a boot parameter would be useful here - that way it is easy to
determine which type of slab object is causing the problems without
needing the end user to run special kernels.

Also, some slab users probably want their own pool of objects that
nobody else can use - mempools are a good example of this - so there
needs to a way of indicating slabs should not be merged into the
kmalloc array.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

  parent reply	other threads:[~2006-08-16  8:13 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-16  2:22 [MODSLAB 0/7] A modular slab allocator V1 Christoph Lameter
2006-08-16  2:22 ` [MODSLAB 1/7] Extract allocpercpu from Slab Christoph Lameter
2006-08-16  2:22 ` [MODSLAB 2/7] Allocator Framework and misc features Christoph Lameter
2006-08-16  2:22 ` [MODSLAB 3/7] A Kmalloc subsystem Christoph Lameter
2006-08-16  7:43   ` Andi Kleen
2006-08-17  0:24     ` Christoph Lameter
2006-08-17  5:19       ` Manfred Spraul
2006-08-17 11:42         ` Andi Kleen
2006-08-17 16:26         ` Christoph Lameter
2006-08-19  7:08           ` Manfred Spraul
2006-08-19 16:46             ` Christoph Lameter
2006-08-19 18:54               ` Manfred Spraul
2006-08-19 19:17                 ` Christoph Lameter
2006-08-18  6:17         ` Christoph Lameter
2006-08-18  7:17           ` KAMEZAWA Hiroyuki
2006-08-18 16:58             ` Christoph Lameter
2006-08-18 18:19               ` KAMEZAWA Hiroyuki
2006-08-18 18:44                 ` Christoph Lameter
2006-08-18 19:13                   ` KAMEZAWA Hiroyuki
2006-08-18 19:19                     ` Christoph Lameter
2006-08-16  2:22 ` [MODSLAB 4/7] Slabulator: Emulate the existing Slab Layer Christoph Lameter
2006-08-16  2:23 ` [MODSLAB 5/7] A slab allocator: SLABIFIER Christoph Lameter
2006-08-16  2:23 ` [MODSLAB 6/7] A slab allocator: NUMA Slab allocator Christoph Lameter
2006-08-16  2:23 ` [MODSLAB 7/7] A slab allocator: Page " Christoph Lameter
2006-08-16  7:52 ` [MODSLAB 0/7] A modular slab allocator V1 Andi Kleen
2006-08-16  8:41   ` Matt Mackall
2006-08-16  9:38     ` David Chinner
2006-08-16 15:08     ` Christoph Lameter
2006-08-16 15:05   ` Christoph Lameter
2006-08-16  8:12 ` David Chinner [this message]
2006-08-16  8:32   ` Andi Kleen
2006-08-16  9:18     ` David Chinner
2006-08-16 15:06   ` Christoph Lameter
2006-08-16 16:15 ` Manfred Spraul
2006-08-16 21:49   ` Christoph Lameter
2006-08-16 22:16   ` Christoph Lameter
2006-08-16 22:34   ` Christoph Lameter
2006-08-16 22:45     ` 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=20060816081208.GL51703024@melbourne.sgi.com \
    --to=dgc@sgi.com \
    --cc=ak@suse.de \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=marcelo@kvack.org \
    --cc=mpm@selenic.com \
    --cc=nickpiggin@yahoo.com.au \
    /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