From: David Howells <dhowells@redhat.com>
To: Vasily Averin <vvs@sw.ru>
Cc: Neil Brown <neilb@suse.de>, Jan Blunck <jblunck@suse.de>,
Olaf Hering <olh@suse.de>, Balbir Singh <balbir@in.ibm.com>,
Kirill Korotaev <dev@openvz.org>,
dhowells@redhat.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [Q] missing unused dentry in prune_dcache()?
Date: Fri, 27 Oct 2006 11:42:49 +0100 [thread overview]
Message-ID: <22562.1161945769@redhat.com> (raw)
In-Reply-To: <4541BDE2.6050703@sw.ru>
Vasily Averin <vvs@sw.ru> wrote:
> Therefore I believe that my patch is optimal solution.
I'm not sure that prune_dcache() is particularly optimal. If we're looking to
prune for a specific superblock, it may scan most of the dentry_unused list
several times, once for each dentry it eliminates.
Imagine the list with a million dentries on it. Imagine further that all the
dentries you're trying to eliminate are up near the head end: you're going to
have to scan most of the list several times unnecessarily; if you're asked to
kill 128 dentries, you might wind up examining on the order of 100,000,000
dentries, 99% of which you scan 128 times.
I wonder if this could be improved by making the assumption that there won't be
any entries inserted tailwards of where we've just looked. The problem is that
if dcache_lock is dropped, we've no way of keeping track of the current
position without inserting a marker into the list.
Now we could do the marker thing quite easily. We'd have to insert a dummy
dcache entry, probably with d_sb pointing to some special location that is
recognised as saying "that dentry is a marker".
We could do something like the attached patch, for example. Note that the
patch compiles, but I haven't tested it. It also uses a big chunk of stack
space for the marker. It ought to be safe enough with respect to the other
functions that touch that list - all of those deal with specific dentries or
look for dentries by superblock.
David
---
diff --git a/fs/dcache.c b/fs/dcache.c
index eab1bf4..a1cae74 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -395,18 +395,27 @@ static void prune_one_dentry(struct dent
* This function may fail to free any resources if
* all the dentries are in use.
*/
-
+
static void prune_dcache(int count, struct super_block *sb)
{
+ struct dentry marker = {
+ .d_sb = (struct super_block *) &prune_dcache,
+ };
+
+ struct list_head *tmp;
+
spin_lock(&dcache_lock);
+ list_add_tail(&marker.d_lru, &dentry_unused);
+
for (; count ; count--) {
struct dentry *dentry;
- struct list_head *tmp;
struct rw_semaphore *s_umount;
cond_resched_lock(&dcache_lock);
- tmp = dentry_unused.prev;
+ tmp = marker.d_lru.prev;
+ list_del_init(&marker.d_lru);
+
if (sb) {
/* Try to find a dentry for this sb, but don't try
* too hard, if they aren't near the tail they will
@@ -418,9 +427,18 @@ static void prune_dcache(int count, stru
skip--;
tmp = tmp->prev;
}
+ } else {
+ /* We may not be the only pruner */
+ while (tmp != &dentry_unused) {
+ dentry = list_entry(tmp, struct dentry, d_lru);
+ if (dentry->d_sb !=
+ (struct super_block *) &prune_dcache)
+ break;
+ }
}
if (tmp == &dentry_unused)
break;
+ list_add(&marker.d_lru, tmp);
list_del_init(tmp);
prefetch(dentry_unused.prev);
dentry_stat.nr_unused--;
@@ -439,7 +457,7 @@ static void prune_dcache(int count, stru
/* If the dentry was recently referenced, don't free it. */
if (dentry->d_flags & DCACHE_REFERENCED) {
dentry->d_flags &= ~DCACHE_REFERENCED;
- list_add(&dentry->d_lru, &dentry_unused);
+ list_add(&dentry->d_lru, &marker.d_lru);
dentry_stat.nr_unused++;
spin_unlock(&dentry->d_lock);
continue;
@@ -478,12 +496,10 @@ static void prune_dcache(int count, stru
up_read(s_umount);
}
spin_unlock(&dentry->d_lock);
- /* Cannot remove the first dentry, and it isn't appropriate
- * to move it to the head of the list, so give up, and try
- * later
- */
- break;
+ list_add(&dentry->d_lru, &marker.d_lru);
+ dentry_stat.nr_unused++;
}
+ list_del(&marker.d_lru);
spin_unlock(&dcache_lock);
}
next prev parent reply other threads:[~2006-10-27 10:44 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-25 12:30 [Q] missing unused dentry in prune_dcache()? Vasily Averin
2006-10-25 13:51 ` David Howells
2006-10-25 13:58 ` Vasily Averin
2006-10-25 14:23 ` David Howells
2006-10-26 11:36 ` Vasily Averin
2006-10-26 13:25 ` David Howells
2006-10-27 8:05 ` Vasily Averin
2006-10-27 10:42 ` David Howells [this message]
2006-10-27 11:50 ` Vasily Averin
2006-10-27 12:11 ` David Howells
2006-10-27 13:47 ` Vasily Averin
2006-10-27 14:29 ` David Howells
2006-10-27 14:39 ` Kirill Korotaev
2006-10-27 14:05 ` [PATCH 2.6.19-rc3] VFS: per-sb dentry lru list Vasily Averin
2006-10-27 18:06 ` Andrew Morton
2006-10-30 14:24 ` Vasily Averin
2006-10-30 15:08 ` Eric Dumazet
2006-10-30 15:34 ` Kirill Korotaev
2006-10-30 16:09 ` Eric Dumazet
2006-10-30 15:14 ` Kirill Korotaev
2006-10-30 4:24 ` David Chinner
2006-10-30 6:28 ` [Devel] " Kirill Korotaev
2006-10-31 4:38 ` Neil Brown
2006-10-31 10:40 ` David Howells
2006-11-01 6:32 ` Neil Brown
2006-11-01 13:32 ` Vasily Averin
2006-11-14 5:44 ` Neil Brown
2006-11-14 6:12 ` Vasily Averin
2006-10-31 13:08 ` Vasily Averin
2006-11-01 10:55 ` [Devel] " Kirill Korotaev
2006-11-14 4:51 ` Neil Brown
2006-11-14 9:29 ` David Howells
2006-10-27 13:42 ` [PATCH 2.6.19-rc3] VFS: missing unused dentry in prune_dcache() Vasily Averin
2006-10-27 14:24 ` David Howells
2006-10-26 11:49 ` [Q] missing unused dentry in prune_dcache()? Vasily Averin
2006-10-26 12:33 ` David Howells
2006-10-26 13:23 ` David Howells
2006-10-26 13:58 ` Vasily Averin
2006-10-26 14:07 ` David Howells
2006-10-27 6:32 ` Vasily Averin
2006-10-27 6:50 ` Vasily Averin
2006-10-27 9:36 ` David Howells
2006-10-31 13:24 ` [Q] missing ->d_delete() in shrink_dcache_for_umount()? Vasily Averin
2006-10-31 15:06 ` David Howells
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=22562.1161945769@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=dev@openvz.org \
--cc=devel@openvz.org \
--cc=jblunck@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=olh@suse.de \
--cc=vvs@sw.ru \
/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.