From: Ed Tomlinson <tomlins@cam.org>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: 2.5.33-mm1
Date: Tue, 3 Sep 2002 22:51:54 -0400 [thread overview]
Message-ID: <200209032251.54795.tomlins@cam.org> (raw)
On September 3, 2002 09:13 pm, Andrew Morton wrote:
> ext3_inode_cache 959 2430 448 264 270 1
>
> That's 264 pages in use, 270 total. If there's a persistent gap between
> these then there is a problem - could well be that slablru is not locating
> the pages which were liberated by the pruning sufficiently quickly.
Sufficiently quickly is a relative thing. It could also be that by the time
the pages are reclaimed another <n> have been cleaned. IMO its no worst
than have freeable pages on lru from any other source. If we get close to
oom we will call kmem_cache_reap, otherwise we let the lru find the pages.
> Calling kmem_cache_reap() after running the pruners will fix that up.
more specificly kmem_cache_reap will clean the one cache with the most
free pages...
>What on earth is going on with kmem_cache_reap? Am I missing
>something, or is that thing 700% overdesigned? Why not just
>free the darn pages in kmem_cache_free_one()? Maybe hang onto
>a few pages for cache warmth, but heck.
This might be as simple as we can see the free pages in slabs. We
cannot see other freeable pages in the lru. This makes slabs seem
like a problem - just because we can see it.
On the other hand we could setup to call __kmem_cache_shrink_locked
after pruning a cache - as it is now this will use page_cache_release
to free the pages... Need to be careful coding this though.
Andrew, you stated that we need to consider dcache and icache pages
as very important ones. I submit that this is what slablru is doing.
It is keeping more of these objects around than the previous design,
which is what you wanted to see happen.
Still working on a good reply to your design suggestion/questions?
Ed
-------------------------------------------------------
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
next reply other threads:[~2002-09-04 2:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-04 2:51 Ed Tomlinson [this message]
2002-09-04 3:33 ` 2.5.33-mm1 Andrew Morton
2002-09-04 19:25 ` 2.5.33-mm1 Stephen C. Tweedie
2002-09-04 20:18 ` 2.5.33-mm1 Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2002-09-04 9:06 2.5.33-mm2 Andrew Morton
2002-09-04 17:16 ` 2.5.33-mm1 Paul Larson
2002-09-04 18:02 ` 2.5.33-mm1 Andrew Morton
2002-09-04 20:07 ` 2.5.33-mm1 Paul Larson
2002-09-03 4:16 2.5.33-mm1 Andrew Morton
2002-09-04 0:40 ` 2.5.33-mm1 William Lee Irwin III
2002-09-04 0:53 ` 2.5.33-mm1 Rik van Riel
2002-09-04 1:13 ` 2.5.33-mm1 Andrew Morton
2002-09-04 1:15 ` 2.5.33-mm1 William Lee Irwin III
2002-09-04 1:37 ` 2.5.33-mm1 Andrew Morton
2002-09-04 2:55 ` 2.5.33-mm1 Ed Tomlinson
2002-09-04 2:54 ` 2.5.33-mm1 William Lee Irwin III
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=200209032251.54795.tomlins@cam.org \
--to=tomlins@cam.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wli@holomorphy.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