From: David Chinner <dgc@sgi.com>
To: Jan Blunck <jblunck@suse.de>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
viro@zeniv.linux.org.uk
Subject: Re: [patch 5/5] vfs: per superblock dentry unused list
Date: Wed, 31 May 2006 09:56:06 +1000 [thread overview]
Message-ID: <20060530235606.GL8069029@melbourne.sgi.com> (raw)
In-Reply-To: <20060530100633.GH21024@hasse.suse.de>
On Tue, May 30, 2006 at 12:06:33PM +0200, Jan Blunck wrote:
> On Tue, May 30, David Chinner wrote:
>
> > You've just described the embodiment of the two order's of magnitude
> > issue I mentioned. That's not a wrong assumption - think of the
> > above case with global_unused count now being 1.28*10^7 instead of
> > 1.28x10^4. How many dentries do you have to free before freeing any
> > on the small superblock if we don't free one per call? (quick
> > answer: 99.9%).
> >
> > If we shrink one per call, we've freed all 128 dentries while there
> > is still 1*10^5 dentries on the large list. That seems like a much
> > better balance to make within the constraints of the shrinker
> > resolution we have to work with.
>
> With the effect that the dcache is completely useless for small filesystems
> as long as there is one big one.
Not necessarily. I think that as long as the small filesystem is not
being used, then we _should_ be reclaiming slowly from it,
regardless of how big the other filesystems are. That's the way the
global list ends up working now as the dentries for the small
filesystem get purged according to LRU.
> Filesystems where regularily a small amount
> of files is used don't have any cached dentries but the filesystem where
> someone touched every file still has a lot of dentries in cache although they
> are never used again.
Or alternatively small filesystems with no activity and dentries
that will never get used again never get trimmed while the large
fielsytem with lots of activity gets trimmed. This can lead to
thousands of pages being pinned in slabs that we don't try to
free up until we've already free >90% of the overall caches.
That's not very appealing, IMO.
So I suggest the question is this - how do you define "not being
used"? I guess dentry age or "last dentry was added to list at time
X" (recorded in dput()) would be one way of determining this.
Say something like:
dput():
list_add(&dentry->d_lru, &dentry->d_sb->s_unused);
dentry->s_sb->s_unused_age = jiffies +
(&dentry->d_sb->s_dentry_stat.age_limit * HZ);
prune_dcache():
tmp = sb->s_dentry_stat.nr_unused/((unused/count)+1);
if ((tmp == 0) && time_after(jiffies, sb->s_unused_age))
tmp = 1;
That would turn over small unused dentry lists that have not been
modified for age_limit seconds. That means that small caches that
are being used are not reclaimed prematurely, and those small
caches would also be reclaimed after some time if they are not
being used. That seems to address both our concerns.....
Thoughts?
Cheers,
Dave.
--
Dave Chinner
R&D Software Enginner
SGI Australian Software Group
next prev parent reply other threads:[~2006-05-30 23:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20060526110655.197949000@suse.de>
2006-05-29 1:57 ` [patch 0/5] [RFC] vfs: per-superblock unused dentries list David Chinner
[not found] ` <20060526110802.852609000@suse.de>
2006-05-29 2:24 ` [patch 4/5] vfs: per superblock dentry stats David Chinner
2006-05-29 9:43 ` Jan Blunck
[not found] ` <20060526110803.159085000@suse.de>
2006-05-29 3:08 ` [patch 5/5] vfs: per superblock dentry unused list David Chinner
2006-05-29 11:54 ` Jan Blunck
2006-05-30 0:04 ` David Chinner
2006-05-30 10:06 ` Jan Blunck
2006-05-30 23:56 ` David Chinner [this message]
2006-06-01 9:51 [patch 0/5] [PATCH,RFC] vfs: per-superblock unused dentries list (2nd version) jblunck
2006-06-01 9:51 ` [patch 5/5] vfs: per superblock dentry unused list jblunck
-- strict thread matches above, loose matches on Subject: below --
2006-06-16 10:43 [PATCH 0/5] vfs: per-superblock unused dentries list (3rd version) jblunck
2006-06-16 10:43 ` [PATCH 5/5] vfs: per superblock dentry unused list jblunck
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=20060530235606.GL8069029@melbourne.sgi.com \
--to=dgc@sgi.com \
--cc=jblunck@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).