linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Andrew Morton <akpm@digeo.com>
Cc: Ed Tomlinson <tomlins@cam.org>, linux-kernel@vger.kernel.org
Subject: Re: [patch 3/4] slab reclaim balancing
Date: Thu, 26 Sep 2002 20:47:49 +0200	[thread overview]
Message-ID: <3D935655.1030606@colorfullife.com> (raw)
In-Reply-To: 3D9345C4.74CD73B8@digeo.com

Andrew Morton wrote:
> 
> (What Ed said - we do hang onto one page.  And I _have_ measured
> cost in kmem_cache_shrink...)
> 
I totally agree about kmem_cache_shrink - it's total abuse that 
fs/dcache.c calls it regularly. It was intended to be called before 
module unload, or during ifdown, etc.
On NUMA, it's probably worse, because it does an IPI to all cpus. 
dcache.c should not call kmem_cache_shrink, and kmem_cache_reap should 
be improved.

> Before:
> Elapsed: 20.18s User: 192.914s System: 48.292s CPU: 1195.6%
> 
> After:
> Elapsed: 19.798s User: 191.61s System: 43.322s CPU: 1186.4%
> 
> That's for a kernel compile.
> 
UP or SMP?
And was that the complete patch, or just the modification to slab.c?

I've made a microbenchmark of kmem_cache_alloc/free of 4 kb objects, on 
UP, AMD Duron:
		1 object	4 objects
cur		145 cycles	 662 cycles
patched		133 cycles	2733 cycles

Summary:
* for one object, the patch is a slight performance improvement. The 
reason is that the fallback from partial to free list in 
kmem_cache_alloc_one is avoided.
* the overhead of kmem_cache_grow/shrink is around 500 cycles, nearly a 
slowdown of factor 4. The cache had no constructor/destructor.
* everything cache hot state. [100 runs in a loop, loop overhead 
substracted. 98 or 99 runs completed in the given time, except for 
patched-4obj, where 24 runs completed in 2735 cycles, 72 in 2733 cycles]


For SMP and slabs that are per-cpu cached, the change could be right, 
because the arrays should absorb bursts. But I do not think that the 
change is the right approach for UP.

--
	Manfred


  reply	other threads:[~2002-09-26 18:42 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 [this message]
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
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:
  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=3D935655.1030606@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tomlins@cam.org \
    /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).