All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dipankar Sarma <dipankar@in.ibm.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: John M Flinchbaugh <glynis@butterfly.hjsoft.com>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>,
	Maneesh Soni <maneesh@in.ibm.com>
Subject: Re: 2.5.70-bk16: nfs crash
Date: Thu, 12 Jun 2003 21:23:45 +0530	[thread overview]
Message-ID: <20030612155345.GB1438@in.ibm.com> (raw)
In-Reply-To: <16104.40370.828325.379995@charged.uio.no>

On Thu, Jun 12, 2003 at 08:35:14AM -0700, Trond Myklebust wrote:
> >>>>> " " == Dipankar Sarma <dipankar@in.ibm.com> writes:
>      > __d_drop() *must not* initialize d_hash fields. Lockfree lookup
>      > depends on that. If __d_drop() needs to be allowed on an
>      > unhashed dentry, the right thing to do would be to check for
>      > DCACHE_UNHASHED before unhashing. I will submit a patch a
>      > little later to do this.
> 
> Can you please remind us exactly what the benefits of all this are? 
> Why can't d_free() immediately free the memory instead of relying on
> the RCU mechanism?

Because we no longer hold the dcache_lock while doing a d_lookup().
With the dentry still around (RCU wouldn't happen until all CPUs
do a context switch or execute user-level code), lookup can continue
to traverse the hash list while another CPU deletes the currrent
dentry. Once RCU happens, it is guranteed that no other CPU
could be in that dentry during hash list traversal. That is why
we have _rcu versions of the list deletion macros.
Lockfree d_lookup() gives us significant benefits in larger
SMP machines.

Does my patch meet the requirements that you had for __d_drop() ?

Thanks
Dipankar

  reply	other threads:[~2003-06-12 15:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 12:56 2.5.70-bk16: nfs crash John M Flinchbaugh
2003-06-12 13:52 ` Dipankar Sarma
2003-06-12 15:33   ` Dipankar Sarma
2003-06-12 15:35   ` Trond Myklebust
2003-06-12 15:53     ` Dipankar Sarma [this message]
2003-06-12 16:26       ` Trond Myklebust
2003-06-12 16:49         ` Linus Torvalds
2003-06-12 16:55           ` Linus Torvalds
2003-06-12 19:53         ` Dipankar Sarma
2003-06-13  5:24           ` Trond Myklebust
2003-06-13  5:50             ` Dipankar Sarma
2003-06-13  6:13               ` Trond Myklebust
2003-06-13  6:54                 ` Dipankar Sarma
2003-06-13  6:06             ` Dipankar Sarma
2003-06-12 16:30       ` viro
2003-06-12 16:55         ` Dipankar Sarma
2003-06-12 15:49   ` Linus Torvalds
2003-06-12 16:05     ` Dipankar Sarma
2003-06-12 16:18     ` Linus Torvalds
2003-06-12 16:35       ` Dipankar Sarma
2003-06-12 16:47         ` Linus Torvalds
2003-06-13 12:48       ` Maneesh Soni

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=20030612155345.GB1438@in.ibm.com \
    --to=dipankar@in.ibm.com \
    --cc=glynis@butterfly.hjsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    --cc=torvalds@transmeta.com \
    --cc=trond.myklebust@fys.uio.no \
    /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.