archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <>
To: Manfred Spraul <>
Cc: Ed Tomlinson <>,
Subject: Re: [patch 3/4] slab reclaim balancing
Date: Fri, 27 Sep 2002 12:52:15 -0700	[thread overview]
Message-ID: <> (raw)

Manfred Spraul wrote:
> Andrew Morton wrote:
> >
> >>* After flushing a batch back into the lists, the number of free objects
> >>in the lists is calculated. If freeable pages exist and the number
> >>exceeds a target, then the freeable pages above the target are returned
> >>to the page buddy.
> >
> >
> > Probably OK for now.  But slab should _not_ hold onto an unused,
> > cache-warm page.  Because do_anonymous_page() may want one.
> >
> If the per-cpu caches are enabled on UP, too, then this is a moot point:
> by the time a batch is freed from the per-cpu array, it will be cache cold.

Well yes, it's all smoke, mirrors and wishful thinking.  All we can
do is to apply local knowledge of typical behaviour in deciding whether
a page is likely to be usefully reused.

> And btw, why do you think a page is cache-warm when the last object on a
>   page is freed? If the last 32-byte kmalloc is released on a page, 40xx
> bytes are probably cache-cold.

L2 caches are hundreds of K, and a single P4 cacheline is 1/32nd of
a page.  Things are tending in that direction.
> Back to your first problem: You've mentioned excess hits on the
> cache_chain_semaphore. Which app did you use for stress testing?

I think it was dd-to-six-disks.

> Could you run a stress test with the applied patch?

Shall try to.

> I've tried dbench 50, with 128 MB RAM, on uniprocessor, with 2.4:
> There were 9100 calls to kmem_cache_reap, and in 90% of the calls, no
> freeable memory was found. Alltogether, only 1300 pages were freed from
> the slabs.
> Are there just too many calls to kmem_cache_reap()? Perhaps we should
> try to optimize the "nothing freeable exists" logic?

It certainly sounds like it.  Some sort of counter which is accessed
outside locks would be appropriate.  Test that before deciding to
take the lock.

  reply	other threads:[~2002-09-27 19:47 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
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 [this message]
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).