All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, Marcelo Tosatti <marcelo@kvack.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [SLUB 2/3] Large kmalloc pass through. Removal of large general slabs
Date: Tue, 6 Mar 2007 20:40:44 -0600	[thread overview]
Message-ID: <20070307024043.GT23311@waste.org> (raw)
In-Reply-To: <20070307023513.19658.81228.sendpatchset@schroedinger.engr.sgi.com>

On Tue, Mar 06, 2007 at 06:35:16PM -0800, Christoph Lameter wrote:
> Unlimited kmalloc size and removal of general caches >=4.
> 
> We can directly use the page allocator for all allocations 4K and larger. This
> means that no general slabs are necessary and the size of the allocation passed
> to kmalloc() can be arbitrarily large. Remove the useless general caches over 4k.

I've been meaning to do this in SLOB as well. Perhaps it warrants
doing in stock kmalloc? I've got a grand total of 18 of these objects
here.

The downside is this makes them suddenly disappear off the slabinfo
radar.

-- 
Mathematics is the supreme nostalgia of our time.

WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: akpm@osdl.org, Marcelo Tosatti <marcelo@kvack.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Manfred Spraul <manfred@colorfullife.com>
Subject: Re: [SLUB 2/3] Large kmalloc pass through. Removal of large general slabs
Date: Tue, 6 Mar 2007 20:40:44 -0600	[thread overview]
Message-ID: <20070307024043.GT23311@waste.org> (raw)
In-Reply-To: <20070307023513.19658.81228.sendpatchset@schroedinger.engr.sgi.com>

On Tue, Mar 06, 2007 at 06:35:16PM -0800, Christoph Lameter wrote:
> Unlimited kmalloc size and removal of general caches >=4.
> 
> We can directly use the page allocator for all allocations 4K and larger. This
> means that no general slabs are necessary and the size of the allocation passed
> to kmalloc() can be arbitrarily large. Remove the useless general caches over 4k.

I've been meaning to do this in SLOB as well. Perhaps it warrants
doing in stock kmalloc? I've got a grand total of 18 of these objects
here.

The downside is this makes them suddenly disappear off the slabinfo
radar.

-- 
Mathematics is the supreme nostalgia of our time.

--
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-03-07  2:53 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-07  2:35 [SLUB 0/3] SLUB: The unqueued slab allocator V4 Christoph Lameter
2007-03-07  2:35 ` Christoph Lameter
2007-03-07  2:35 ` [SLUB 1/3] SLUB core Christoph Lameter
2007-03-07  2:35   ` Christoph Lameter
2007-03-07  2:35 ` [SLUB 2/3] Large kmalloc pass through. Removal of large general slabs Christoph Lameter
2007-03-07  2:35   ` Christoph Lameter
2007-03-07  2:40   ` Matt Mackall [this message]
2007-03-07  2:40     ` Matt Mackall
2007-03-07  3:22     ` Christoph Lameter
2007-03-07  3:22       ` Christoph Lameter
2007-03-07  9:01   ` Peter Zijlstra
2007-03-07  9:01     ` Peter Zijlstra
2007-03-07 15:34     ` Christoph Lameter
2007-03-07 15:34       ` Christoph Lameter
2007-03-07 18:03       ` Matt Mackall
2007-03-07 18:03         ` Matt Mackall
2007-03-07 18:23         ` Christoph Lameter
2007-03-07 18:23           ` Christoph Lameter
2007-03-07  2:35 ` [SLUB 3/3] Guarantee minimum number of objects in a slab Christoph Lameter
2007-03-07  2:35   ` Christoph Lameter
2007-03-08 10:54 ` [SLUB 0/3] SLUB: The unqueued slab allocator V4 Mel Gorman
2007-03-08 10:54   ` Mel Gorman
2007-03-08 16:48   ` Christoph Lameter
2007-03-08 16:48     ` Christoph Lameter
2007-03-08 17:40     ` Mel Gorman
2007-03-08 17:40       ` Mel Gorman
2007-03-08 18:16       ` Christoph Lameter
2007-03-08 18:16         ` Christoph Lameter
2007-03-09 13:55         ` Mel Gorman
2007-03-09 13:55           ` Mel Gorman
2007-03-08 21:54       ` Christoph Lameter
2007-03-08 21:54         ` Christoph Lameter
2007-03-09 14:00         ` Mel Gorman
2007-03-09 14:00           ` Mel Gorman
2007-03-09 16:40           ` Christoph Lameter
2007-03-09 16:40             ` Christoph Lameter
2007-03-09 15:06         ` Mel Gorman
2007-03-09 15:06           ` Mel Gorman
2007-03-09 17:21           ` Christoph Lameter
2007-03-09 17:21             ` Christoph Lameter
2007-03-08 17:46   ` Christoph Lameter
2007-03-08 17:46     ` 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=20070307024043.GT23311@waste.org \
    --to=mpm@selenic.com \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=manfred@colorfullife.com \
    --cc=marcelo@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 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.