mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: Matt Mackall <mpm@selenic.com>,
	Christoph Lameter <clameter@sgi.com>, Ingo Molnar <mingo@elte.hu>,
	Hugh Dickins <hugh@veritas.com>, Andi Kleen <andi@firstfloor.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] greatly reduce SLOB external fragmentation
Date: Thu, 10 Jan 2008 08:13:03 -0800 (PST)	[thread overview]
Message-ID: <alpine.LFD.1.00.0801100749000.3148@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0801101251200.14402@sbz-30.cs.Helsinki.FI>



On Thu, 10 Jan 2008, Pekka J Enberg wrote:
> 
> We probably don't have the same version of GCC which perhaps affects 
> memory layout (struct sizes) and thus allocation patterns?

No, struct sizes will not change with compiler versions - that would 
create binary incompatibilities for libraries etc.

So apart from the kernel itself working around some old gcc bugs by making 
spinlocks have different size depending on the compiler version, sizes of 
structures should be the same (as long as the configuration is the same, 
of course).

However, a greedy first-fit allocator will be *very* sensitive to 
allocation pattern differences, so timing will probably make a big 
difference. In contrast, SLUB and SLAB both use fixed sizes per allocation 
queue, which makes them almost totally impervious to any allocation 
pattern from different allocation sizes (they still end up caring about 
the pattern *within* one size, but those tend to be much stabler).

There really is a reason why traditional heaps with first-fit are almost 
never used for any real loads.

(I'm not a fan of slabs per se - I think all the constructor/destructor 
crap is just that: total crap - but the size/type binning is a big deal, 
and I think SLOB was naïve to think a pure first-fit makes any sense. Now 
you guys are size-binning by just two or three bins, and it seems to make 
a difference for some loads, but compared to SLUB/SLAB it's a total hack).

I would suggest that if you guys are really serious about memory use, try 
to do a size-based heap thing, and do best-fit in that heap. Or just some 
really simple size-based binning, eg

	if (size > 2*PAGE_SIZE)
		goto page_allocator;
	bin = lookup_bin[(size+31) >> 5];

or whatever. Because first-fit is *known* to be bad.

At try to change it to address-ordered first-fit or something (which is 
much more complex than just plain LIFO, but hey, that's life).

I haven't checked much, but I *think* SLOB is just basic first-fit 
(perhaps the "next-fit" variation?) Next-fit is known to be EVEN WORSE 
than the simple first-fit when it comes to fragmentation (so no, Knuth was 
not always right - let's face it, much of Knuth is simply outdated).

			Linus

  parent reply	other threads:[~2008-01-10 16:14 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-02 18:43 [PATCH] procfs: provide slub's /proc/slabinfo Hugh Dickins
2008-01-02 18:53 ` Christoph Lameter
2008-01-02 19:09 ` Pekka Enberg
2008-01-02 19:35   ` Linus Torvalds
2008-01-02 19:45     ` Linus Torvalds
2008-01-02 19:49     ` Pekka Enberg
2008-01-02 22:50     ` Matt Mackall
2008-01-03  8:52       ` Ingo Molnar
2008-01-03 16:46         ` Matt Mackall
2008-01-04  2:21           ` Christoph Lameter
2008-01-04  2:45             ` Andi Kleen
2008-01-04  4:34               ` Matt Mackall
2008-01-04  9:17               ` Peter Zijlstra
2008-01-04 20:37                 ` Christoph Lameter
2008-01-04  4:11             ` Matt Mackall
2008-01-04 20:34               ` Christoph Lameter
2008-01-04 20:55                 ` Matt Mackall
2008-01-04 21:36                   ` Christoph Lameter
2008-01-04 22:30                     ` Matt Mackall
2008-01-05 20:16                       ` Christoph Lameter
2008-01-05 16:21               ` Pekka J Enberg
2008-01-05 17:14                 ` Andi Kleen
2008-01-05 20:05                 ` Christoph Lameter
2008-01-07 20:12                   ` Pekka J Enberg
2008-01-06 17:51                 ` Matt Mackall
2008-01-07 18:06                   ` Pekka J Enberg
2008-01-07 19:03                     ` Matt Mackall
2008-01-07 19:53                       ` Pekka J Enberg
2008-01-07 20:44                       ` Pekka J Enberg
2008-01-10 10:04                       ` Pekka J Enberg
2008-01-09 19:15                     ` [RFC PATCH] greatly reduce SLOB external fragmentation Matt Mackall
2008-01-09 22:43                       ` Pekka J Enberg
2008-01-09 22:59                         ` Matt Mackall
2008-01-10 10:02                           ` Pekka J Enberg
2008-01-10 10:54                             ` Pekka J Enberg
2008-01-10 15:44                               ` Matt Mackall
2008-01-10 16:13                               ` Linus Torvalds [this message]
2008-01-10 17:49                                 ` Matt Mackall
2008-01-10 18:28                                   ` Linus Torvalds
2008-01-10 18:42                                     ` Matt Mackall
2008-01-10 19:24                                       ` Christoph Lameter
2008-01-10 19:44                                         ` Matt Mackall
2008-01-10 19:51                                           ` Christoph Lameter
2008-01-10 19:41                                       ` Linus Torvalds
2008-01-10 19:46                                         ` Christoph Lameter
2008-01-10 19:53                                         ` Andi Kleen
2008-01-10 19:52                                           ` Christoph Lameter
2008-01-10 19:16                                   ` Christoph Lameter
2008-01-10 19:23                                     ` Matt Mackall
2008-01-10 19:31                                       ` Christoph Lameter
2008-01-10 21:25                                   ` Jörn Engel
2008-01-10 18:13                                 ` Andi Kleen
2008-07-30 21:51                                 ` Pekka J Enberg
2008-07-30 22:00                                   ` Linus Torvalds
2008-07-30 22:22                                     ` Pekka Enberg
2008-07-30 22:35                                       ` Linus Torvalds
2008-07-31  0:42                                         ` malc
2008-07-31  1:03                                         ` Matt Mackall
2008-07-31  1:09                                     ` Matt Mackall
2008-07-31 14:11                                       ` Andi Kleen
2008-07-31 15:25                                         ` Christoph Lameter
2008-07-31 16:03                                           ` Andi Kleen
2008-07-31 16:05                                             ` Christoph Lameter
2008-07-31 14:26                                       ` Christoph Lameter
2008-07-31 15:38                                         ` Matt Mackall
2008-07-31 15:42                                           ` Christoph Lameter
2008-01-10  2:46                         ` Matt Mackall
2008-01-10 10:03                       ` Pekka J Enberg
2008-01-03 20:31         ` [PATCH] procfs: provide slub's /proc/slabinfo 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=alpine.LFD.1.00.0801100749000.3148@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=clameter@sgi.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mpm@selenic.com \
    --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

all inboxes | Powered by JetHome®