From: Matt Mackall <mpm@selenic.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Pekka J Enberg <penberg@cs.helsinki.fi>,
Mel Gorman <mel@csn.ul.ie>,
linux-mm@kvack.org
Subject: Re: [patch 6/8] slub: Adjust order boundaries and minimum objects per slab.
Date: Mon, 3 Mar 2008 15:34:13 -0600 [thread overview]
Message-ID: <20080303213412.GD10223@waste.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0803030950010.6010@schroedinger.engr.sgi.com>
On Mon, Mar 03, 2008 at 09:52:55AM -0800, Christoph Lameter wrote:
> On Sat, 1 Mar 2008, Pekka J Enberg wrote:
>
> > On Fri, 29 Feb 2008, Christoph Lameter wrote:
> > > The defaults for slab are also 60 objects per slab. The PAGE_SHIFT says
> > > nothing about the big iron. Our new big irons have a page shift of 12 and
> > > are x86_64.
> >
> > Where is that objects per slab limit? I only see calculate_slab_order()
> > trying out bunch of page orders until we hit "acceptable" internal
> > fragmentation. Also keep in mind how badly SLAB compares to SLUB and SLOB
> > in terms of memory efficiency.
>
> slub_min_objects sets that limit.
>
> > On Fri, 29 Feb 2008, Christoph Lameter wrote:
> > > We could drop the limit if CONFIG_EMBEDDED is set but then this may waste
> > > space. A higher order allows slub to reach a higher object density (in
> > > particular for objects 500-2000 bytes size).
> >
> > I am more worried about memory allocated for objects that are not used
> > rather than memory wasted due to bad fitting.
>
> Is there any way to quantify this? This is likely only an effect that
> mostly matters for rarely used slabs (the merging reduces that effect).
> F.e. fitting more inodes or dentries into a single slab increases object
> density.
On the other hand, a single object can now pin 64k in memory rather
than 4k. So when we collapse some cache under memory pressure, we're
not likely to free as much.
I know you've put a lot of effort into dealing with the dcache and
icache instances of this, but this could very well offset most of that.
Also, we might consider only allocating an order-1 slab if we've
filled an order-0, and so on. When we hit pressure, we kick our
order counter back to 0.
--
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>
next prev parent reply other threads:[~2008-03-03 21:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080229044803.482012397@sgi.com>
[not found] ` <20080229044820.044485187@sgi.com>
2008-02-29 8:13 ` [patch 7/8] slub: Make the order configurable for each slab cache Pekka Enberg
2008-02-29 19:37 ` Christoph Lameter
2008-03-01 9:47 ` Pekka Enberg
2008-03-03 17:49 ` Christoph Lameter
2008-03-03 22:56 ` Pekka Enberg
2008-03-03 23:36 ` Christoph Lameter
[not found] ` <20080229044820.298792748@sgi.com>
2008-02-29 8:13 ` [patch 8/8] slub: Simplify any_slab_object checks Pekka Enberg
[not found] ` <20080229044819.800974712@sgi.com>
2008-02-29 8:19 ` [patch 6/8] slub: Adjust order boundaries and minimum objects per slab Pekka Enberg
2008-02-29 19:41 ` Christoph Lameter
2008-03-01 9:58 ` Pekka J Enberg
2008-03-03 17:52 ` Christoph Lameter
2008-03-03 21:34 ` Matt Mackall [this message]
2008-03-03 22:36 ` Christoph Lameter
[not found] ` <20080229044818.999367120@sgi.com>
2008-02-29 8:59 ` [patch 3/8] slub: Update statistics handling for variable order slabs Pekka Enberg
2008-02-29 19:43 ` Christoph Lameter
2008-03-01 10:29 ` Pekka Enberg
2008-03-04 12:20 ` [patch 0/8] slub: Fallback to order 0 and variable order slab support Mel Gorman
2008-03-04 18:53 ` Christoph Lameter
2008-03-05 18:28 ` Mel Gorman
2008-03-05 18:52 ` Christoph Lameter
2008-03-06 22:04 ` Mel Gorman
2008-03-06 22:18 ` Christoph Lameter
2008-03-07 12:17 ` Mel Gorman
2008-03-07 19:50 ` Christoph Lameter
2008-03-04 19:01 ` Matt Mackall
2008-03-05 0:04 ` 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=20080303213412.GD10223@waste.org \
--to=mpm@selenic.com \
--cc=clameter@sgi.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--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.