From: Ed Tomlinson <tomlins@cam.org>
To: Alexander Viro <viro@math.psu.edu>, Ed Tomlinson <tomlins@cam.org>
Cc: Rik van Riel <riel@conectiva.com.br>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Re: memory usage - dentry_cacheg
Date: Fri, 13 Apr 2001 00:45:41 -0400 [thread overview]
Message-ID: <01041300454100.06447@oscar> (raw)
In-Reply-To: <Pine.GSO.4.21.0104122154560.22287-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0104122154560.22287-100000@weyl.math.psu.edu>
On Thursday 12 April 2001 22:03, Alexander Viro wrote:
> On Thu, 12 Apr 2001, Ed Tomlinson wrote:
> > On Thursday 12 April 2001 11:12, Alexander Viro wrote:
> > What prompted my patch was observing situations where the icache (and
> > dcache too) got so big that they were applying artifical pressure to the
> > page and buffer caches. I say artifical since checking the stats these
> > caches showed over 95% of the entries unused. At this point there is
> > usually another 10% or so of objects allocated by the slab caches but not
> > accounted for in the stats (not a problem they are accounted if the cache
> > starts using them).
>
> "Unused" as in "->d_count==0"? That _is_ OK. Basically, you will have
> positive ->d_count only on directories and currently opened files.
> E.g. during compile in /usr/include/* you will have 3-5 file dentries
> with ->d_count > 0 - ones that are opened _now_. It doesn't mean that
> everything else rest is unused in any meaningful sense. Can be freed - yes,
> but that's a different story.
>
> If you are talking about "unused" from the slab POV - _ouch_. Looks like
> extremely bad fragmentation ;-/ It's surprising, and if that's thte case
> I'd like to see more details.
>From the POV of dentry_stat.nr_unused. From the slab POV, dentry_stat.nr_dentry
always equals the number of objects used as reported in /proc/slabinfo. If I
could remember my stats from ages back I could take a stab at estimating the
fragmentation... From experience if you look at memory_pressure before and
after a shrink of the dcache you will usually see it decrease if there if
there is more that 75% or so free reported by dentry_stat.nr_unused.
The inode cache is not as good. With fewer inodes per page (slab) I
would expect that percentage to be lower. Instead it usually has to be
above 80% to get pages free...
I am trying your change now.
Ed Tomlinson
next prev parent reply other threads:[~2001-04-13 4:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-11 11:36 Fwd: Re: memory usage - dentry_cache Marcin Kowalski
2001-04-12 4:48 ` Fwd: Re: memory usage - dentry_cacheg Andreas Dilger
2001-04-12 5:45 ` Alexander Viro
2001-04-12 6:53 ` [PATCH] " Jeff Garzik
2001-04-12 7:10 ` [CFT][PATCH] Re: Fwd: Re: memory usage - dentry_cache Alexander Viro
2001-04-12 8:44 ` David S. Miller
2001-04-12 12:27 ` Marcin Kowalski
2001-04-12 12:43 ` Yoann Vandoorselaere
2001-04-12 13:54 ` Alexander Viro
2001-04-12 17:27 ` Andreas Dilger
2001-04-12 7:00 ` Fwd: Re: memory usage - dentry_cacheg Andreas Dilger
2001-04-12 7:27 ` [race][RFC] d_flags use Alexander Viro
2001-04-12 8:01 ` David S. Miller
2001-04-12 8:06 ` Alexander Viro
2001-04-12 11:46 ` [PATCH] Re: memory usage - dentry_cacheg Ed Tomlinson
2001-04-12 14:56 ` Rik van Riel
2001-04-12 15:12 ` Alexander Viro
2001-04-13 1:34 ` Ed Tomlinson
2001-04-13 2:03 ` Alexander Viro
2001-04-13 4:45 ` Ed Tomlinson [this message]
2001-04-13 13:36 ` Ed Tomlinson
2001-04-12 15:30 ` Marcin Kowalski
2001-04-14 3:28 ` Paul
2001-04-12 14:34 ` [PATCH] Re: Fwd: " Jan Harkes
2001-04-12 14:50 ` Alexander Viro
2001-04-12 15:07 ` Rik van Riel
2001-04-12 15:27 ` Alexander Viro
2001-04-12 15:42 ` Alexander Viro
2001-04-12 15:48 ` Rik van Riel
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=01041300454100.06447@oscar \
--to=tomlins@cam.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=viro@math.psu.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.