From: Rusty Russell <rusty@rustcorp.com.au>
To: dipankar@in.ibm.com
Cc: maneesh@in.ibm.com, lse-tech@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Paul.McKenney@us.ibm.com,
viro@math.psu.edu, anton@samba.org, andrea@suse.de,
tytso@mit.edu, riel@conectiva.com.br
Subject: Re: [RFC] Peeling off dcache_lock
Date: Tue, 29 Jan 2002 11:33:19 +1100 [thread overview]
Message-ID: <20020129113319.6b3a33af.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20020125150000.B1782@in.ibm.com>
In-Reply-To: <20020121174039.D8289@in.ibm.com> <20020125150000.B1782@in.ibm.com>
On Fri, 25 Jan 2002 15:00:00 +0530
Dipankar Sarma <dipankar@in.ibm.com> wrote:
> Since there has been speculation about the throughput #s for lower end,
> I have put up the comparison graph in the same page
> (http://lse.sf.net/locking/dcache/dcache_lock.html).
Have you thought about getting rid of the lru list altogether, and
traverse one chain at a time in prune_dcache, using the referenced bit as
a straight clock algorithm:
spin_lock(&dentry->d_lock);
if (atomic_read(dentry->dcount) == 0) {
if (dentry->d_vfs_flags & DCACHE_REFERENCED)
dentry->d_vfs_flags &= ~DCACHE_REFERENCED;
else
prune_one_dentry(dentry);
}
spin_unlock(&dentry->d_lock);
This can be optimized by doing a dcount check outside the loop, and the
global dcache lock can be dropped between each hash chain, and we can
store the last traversed hash chain in a static var, protected by the
global lock.
I'm just not sure how much the "semi" LRU wins us...
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
prev parent reply other threads:[~2002-01-29 0:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-21 12:10 [RFC] Peeling off dcache_lock Maneesh Soni
2002-01-24 7:02 ` Rusty Russell
[not found] ` <20020125114410.Z8289@in.ibm.com>
2002-01-27 3:42 ` Rusty Russell
2002-02-12 14:11 ` [PATCH][RFC] Peeling off dcache_lock - Ver 2 Maneesh Soni
2002-01-25 9:30 ` [RFC] Peeling off dcache_lock Dipankar Sarma
2002-01-29 0:33 ` Rusty Russell [this message]
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=20020129113319.6b3a33af.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=Paul.McKenney@us.ibm.com \
--cc=andrea@suse.de \
--cc=anton@samba.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=maneesh@in.ibm.com \
--cc=riel@conectiva.com.br \
--cc=tytso@mit.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox