archive mirror
 help / color / mirror / Atom feed
From: Ed Tomlinson <>
To: Andrew Morton <>,
	Manfred Spraul <>
Subject: Re: [patch 3/4] slab reclaim balancing
Date: Thu, 26 Sep 2002 20:41:11 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On September 26, 2002 05:39 pm, Andrew Morton wrote:
> Manfred Spraul wrote:
> > Andrew Morton wrote:
> > Btw, 140 cycles for kmem_cache_alloc+free is inflated - someone enabled
> > kmem_cache_alloc_head() even in the no-debugging version.
> > As expected, done by Andrea, who neither bothered to cc me, nor actually
> > understood the code.
> hm, OK.  Sorry, I did not realise that you were this closely
> interested/involved with slab, so things have been sort of
> going on behind your back :(

Nor did I realize this...  The reasoning behind quickly giving pages back to the 
system was fairly simple.  Previous vm experiements showed that lazy freeing
of pages from the lru was not a good performer.  When the first versions of
slablru went into mm we noticed that large numbers of pages (thousands) were
free but not reclaimed.  This was working as designed - the conclusion was that
slablru was over designed and that lazy removal was probably not such a good
idea.  The slabasap patch that started this thread was the fix for this.

There is no dispute that in some cases it will be slower from a slab perspective.  As
Andrew and you have discussed there are things that can be done to speed things 
up.  Is not the question really, "Are the vm and slab faster together when slab pages 
are freed asap?"

As it stands now we could remove quite a bit of code from slab.  There is no longer
a need for most of the kmem_cache_shrink family, nor is kmem_cache_reap needed
any more.  This simpilifes slab.  If we also enable the per cpu arrays for UP the code
is even cleaner (and hopefully faster).

Manfred, slab is currently using typedefs.  Andrews has stated that he and Linus are
trying to remove these from the kernel.  When I code the cleanup patches for slabasap
(provided it proves itself) shall I clean them out too?

Ed Tomlinson

  reply	other threads:[~2002-09-27  0:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-26 14:13 [patch 3/4] slab reclaim balancing Manfred Spraul
2002-09-26 14:20 ` William Lee Irwin III
2002-09-26 15:24   ` Manfred Spraul
2002-09-26 17:37 ` Andrew Morton
2002-09-26 18:47   ` Manfred Spraul
2002-09-26 19:49     ` Andrew Morton
2002-09-26 20:49       ` Manfred Spraul
2002-09-26 21:39         ` Andrew Morton
2002-09-27  0:41           ` Ed Tomlinson [this message]
2002-09-27 17:24             ` Manfred Spraul
2002-09-27 18:26               ` Andrew Morton
2002-09-27 19:38                 ` Manfred Spraul
2002-09-27 19:52                   ` Andrew Morton
2002-09-27 15:59           ` Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
2002-09-26  4:08 Andrew Morton
2002-09-26 11:39 ` Ed Tomlinson
2002-09-26 15:09 ` Ed Tomlinson

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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).