linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pekka J Enberg <penberg@cs.helsinki.fi>
To: Christoph Lameter <clameter@sgi.com>
Cc: Mel Gorman <mel@csn.ul.ie>, Matt Mackall <mpm@selenic.com>,
	linux-mm@kvack.org
Subject: Re: [patch 6/8] slub: Adjust order boundaries and minimum objects per slab.
Date: Sat, 1 Mar 2008 11:58:46 +0200 (EET)	[thread overview]
Message-ID: <Pine.LNX.4.64.0803011148320.19118@sbz-30.cs.Helsinki.FI> (raw)
In-Reply-To: <Pine.LNX.4.64.0802291139560.11084@schroedinger.engr.sgi.com>

Hi Christoph,

On Fri, 29 Feb 2008, Pekka Enberg wrote:
> > I can see why you want to change the defaults for big iron but why not keep
> > the existing PAGE_SHIFT check which leaves embedded and regular desktop
> > unchanged?
 
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.

Maybe we can use total amount of memory as some sort of heuristic to 
determine the defaults? That way boxes with lots of memory get to use 
larger orders for better performance whereas smaller boxes are more 
memory efficient.

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.

			Pekka

--
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:[~2008-03-01  9:58 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 [this message]
2008-03-03 17:52         ` Christoph Lameter
2008-03-03 21:34           ` Matt Mackall
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=Pine.LNX.4.64.0803011148320.19118@sbz-30.cs.Helsinki.FI \
    --to=penberg@cs.helsinki.fi \
    --cc=clameter@sgi.com \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=mpm@selenic.com \
    /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).