All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: maneesh@in.ibm.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Peeling off dcache_lock
Date: Sun, 27 Jan 2002 14:42:13 +1100	[thread overview]
Message-ID: <20020127144213.09bded56.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20020125114410.Z8289@in.ibm.com>
In-Reply-To: <20020121174039.D8289@in.ibm.com> <20020124180241.4d266b3e.rusty@rustcorp.com.au> <20020125114410.Z8289@in.ibm.com>

On Fri, 25 Jan 2002 11:44:11 +0530
Maneesh Soni <maneesh@in.ibm.com> wrote:

> On Thu, Jan 24, 2002 at 06:02:41PM +1100, Rusty Russell wrote:
> > Hi Maneesh!
> > 
> > 	Fantastic work!  A couple of questions, and a trivial patch:
> 
> Hi Rusty,
> 
> Thanks for code review.

Hey, anything that wins 20% on (32-way) dbench is worth reading 8)

> >  o Am I correct in asserting that you could change all the
> >    "list_empty(dentry->dhash)" tests to
> >    "dentry->d_vfs_flags & DCACHE_DEFERRED_FREE" tests, and hence change the
> >    list_del_init() to list_del() in unhash, and thus remove the d_nexthash
> >    field altogether?
> I agree that d_next_hash is a sort of hack and want to remove it. I think
> we have tried removing it in the way you are suggesting. But we never got a 
> stable code. I will have to look at this some what more.

Hmm... I finally have a dual x86 box here, so I can play with this as well.

> >  o d_lookup looks like it can return an DCACHE_DEFERRED_FREE dentry: this
> >    seems wrong: shouldn't it loop here?
> Actually d_lookup will fail if the found dentry has DCACHE_DEFERRED_FREE set.

ACK.  Sorry, my mistake.

> I will do all these corrections in the next version very soon.

I wouldn't say "corrections": your code is very nice. I'm looking forward
to your next iteration!

> > Any chance of you making it to http://linux.conf.au next month BTW?
> Probably not as I am getting married next month ;-) and lots of shopping is
> still remaining ;-).

Oh, congratulations!  Perhaps I shall have to find a conference in India
then 8)

Thanks!
Rusty.
-- 
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

  parent reply	other threads:[~2002-01-28 22:08 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 [this message]
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

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=20020127144213.09bded56.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    /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.