public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	torvalds@transmeta.com
Subject: Re: Purpose of the mm/slab.c changes
Date: Sun, 9 Sep 2001 17:33:13 +0200	[thread overview]
Message-ID: <20010909173313.V11329@athlon.random> (raw)
In-Reply-To: <3B9B4CFE.E09D6743@colorfullife.com> <20010909162613.Q11329@athlon.random> <001201c13942$b1bec9a0$010411ac@local>
In-Reply-To: <001201c13942$b1bec9a0$010411ac@local>; from manfred@colorfullife.com on Sun, Sep 09, 2001 at 05:18:00PM +0200

On Sun, Sep 09, 2001 at 05:18:00PM +0200, Manfred Spraul wrote:
> >
> > it provides lifo allocations from both partial and unused slabs.
> >
> 
> lifo/fifo for unused slabs is obviously superflous - free is free, it
> doesn't matter which free page is used first/last.

then why don't you also make fifo the buddy allocator and the partial
list as well if free is free and fifo/lifo doesn't matter?

> Did you run any benchmarks? If yes, could you post them?

I didn't run any specific benchmark for such change but please let me
know if you can find that any real benchmark is hurted by it. I think
the cleanup and the potential for lifo in the free slabs is much more
sensible than the other factors you mentioned, of course there's less
probability of having to fall into the free slabs rather than in the
partial ones during allocations, but that doesn't mean that cannot
happen very often, but I will glady suggest to remove it if you prove me
wrong. All I'm saying here is that the dummy allocations with no access
to the ram returned are not interesting numbers.

Andrea

  reply	other threads:[~2001-09-09 15:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-09 11:05 Purpose of the mm/slab.c changes Manfred Spraul
2001-09-09 14:26 ` Andrea Arcangeli
2001-09-09 15:18   ` Manfred Spraul
2001-09-09 15:33     ` Andrea Arcangeli [this message]
2001-09-11 18:41       ` Manfred Spraul
2001-09-11 19:36         ` Andrea Arcangeli
2001-09-11 20:43           ` Manfred Spraul
2001-09-12 14:18             ` Andrea Arcangeli
2001-09-09 16:12     ` Alan Cox
2001-09-09 16:25     ` Linus Torvalds
2001-09-09 16:47       ` Alan Cox
2001-09-09 16:55         ` Manfred Spraul
2001-09-09 17:01         ` Linus Torvalds
2001-09-09 17:22           ` Manfred Spraul
2001-09-09 17:27           ` arjan
2001-09-09 17:35           ` Andrea Arcangeli
2001-09-09 17:30         ` Andrea Arcangeli
2001-09-09 17:59         ` Fwd: 2.4.10-pre6 ramdisk driver broken? won't compile Stephan Gutschke
2001-09-09 20:26         ` Purpose of the mm/slab.c changes Rik van Riel
2001-09-15  0:29       ` Albert D. Cahalan
2001-09-09 20:23     ` Rik van Riel
2001-09-09 20:44       ` Davide Libenzi
2001-09-09 20:45         ` Rik van Riel
2001-09-09 20:58           ` Davide Libenzi
2001-09-22 12:28             ` Ralf Baechle
2001-09-22 21:03               ` Davide Libenzi
2001-09-22 21:36                 ` David S. Miller
2001-09-10  2:28     ` Daniel Phillips

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=20010909173313.V11329@athlon.random \
    --to=andrea@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=torvalds@transmeta.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