From: Matt Mackall <mpm@selenic.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>, Mel Gorman <mel@csn.ul.ie>,
linux-mm@kvack.org
Subject: Re: [patch 7/8] slub: Adjust order boundaries and minimum objects per slab.
Date: Sat, 16 Feb 2008 14:20:59 -0600 [thread overview]
Message-ID: <1203193259.6324.12.camel@cinder.waste.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0802161059420.25573@schroedinger.engr.sgi.com>
On Sat, 2008-02-16 at 11:00 -0800, Christoph Lameter wrote:
> On Sat, 16 Feb 2008, Pekka Enberg wrote:
>
> > These look quite excessive from memory usage point of view. I saw you dropping
> > DEFAULT_MAX_ORDER to 4 but it seems a lot for embedded guys, at least?
>
> What would be a good max order then? 4 means we can allocate a 64k segment
> for 16 4k objects.
Why are 4k objects even going through SLUB?
What happens if we have 8k free and try to allocate one 4k object
through SLUB?
Using an order greater than 0 is generally frowned upon. Kernels can and
do get into situations where they can't find two contiguous pages, which
is why we've gone to so much trouble on x86 to fit into a single page of
stack.
--
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-02-16 20:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080215230811.635628223@sgi.com>
[not found] ` <20080215230853.165783772@sgi.com>
2008-02-16 8:12 ` [patch 1/8] slub: rename slab_objects to show_slab_objects Pekka Enberg
[not found] ` <20080215230854.890557911@sgi.com>
2008-02-16 8:46 ` [patch 8/8] slub: Make the order configurable for each slab cache Pekka Enberg
[not found] ` <20080215230853.397873101@sgi.com>
2008-02-16 8:55 ` [patch 2/8] slub: Add function to determine the amount of objects that can reside in a given slab Pekka Enberg
[not found] ` <20080215230853.705338997@sgi.com>
2008-02-16 8:57 ` [patch 3/8] slub: for_each_object must be passed the number of objects in a slab Pekka Enberg
[not found] ` <20080215230853.942719945@sgi.com>
2008-02-16 9:01 ` [patch 4/8] slub: Update statistics handling for variable order slabs Pekka Enberg
[not found] ` <20080215230854.132617990@sgi.com>
2008-02-16 9:06 ` [patch 5/8] slub: Fallback to order 0 during slab page allocation Pekka Enberg
[not found] ` <20080215230854.391263372@sgi.com>
2008-02-16 9:07 ` [patch 6/8] slub: Drop fallback to page allocator method Pekka Enberg
[not found] ` <20080215230854.643455255@sgi.com>
2008-02-16 9:13 ` [patch 7/8] slub: Adjust order boundaries and minimum objects per slab Pekka Enberg
2008-02-16 19:00 ` Christoph Lameter
2008-02-16 20:20 ` Matt Mackall [this message]
2008-02-16 22:09 ` Christoph Lameter
2008-02-16 9:35 ` [patch 0/8] [RFC] SLUB: Variable order slab support Pekka Enberg
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=1203193259.6324.12.camel@cinder.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox