public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@lst.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill()
Date: Sat, 17 Feb 2018 00:49:35 +0100	[thread overview]
Message-ID: <87lgfs3374.fsf@linutronix.de> (raw)
In-Reply-To: <CA+55aFzfug3S_dRrHDh=Zdat0KZVar13NQVzyqXd3-xHLzeSjA@mail.gmail.com> (Linus Torvalds's message of "Fri, 16 Feb 2018 15:31:22 -0800")

On 2018-02-17, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> dentry_kill() calls both dentry_lock_inode() and lock_parent() in the
>> common case. So by changing the semantics of lock_parent(), I am
>> removing two "recheck in case I dropped" in the common case rather
>> than just the one you pointed out.
>
> Ok, that would be lovely, but doesn't that end up being a nasty patch?

After reading your initial feedback my idea was to change both
lock_parent() and dentry_lock_inode() to not only communicate _if_ the
lock was successful, but also if d_lock was dropped in the process. (For
example, with a tristate rather than boolean return value.) Then callers
would know if they needed to recheck the dentry contents.

> So it may be that my dislike of the "re-check after possibly dropping
> the lock" is not really about the re-checking, but about just how it
> made that function look much more complicated.

I understand what you are saying and I appreciate the comments. I will
code up some variations for myself and try to pick the one that is the
least complicated for my v2.

John Ogness

  reply	other threads:[~2018-02-16 23:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16 15:09 [PATCH 0/4] fs/dcache: avoid trylock loops John Ogness
2018-02-16 15:09 ` [PATCH 1/4] fs/dcache: Remove stale comment from dentry_kill() John Ogness
2018-02-16 15:09 ` [PATCH 2/4] fs/dcache: Move dentry_kill() below lock_parent() John Ogness
2018-02-16 15:09 ` [PATCH 3/4] fs/dcache: Avoid the try_lock loop in d_delete() John Ogness
2018-02-16 17:10   ` Peter Zijlstra
2018-02-16 17:30   ` Peter Zijlstra
2018-02-22  5:18   ` Al Viro
2018-02-22  8:35     ` John Ogness
2018-02-16 15:09 ` [PATCH 4/4] fs/dcache: Avoid the try_lock loops in dentry_kill() John Ogness
2018-02-16 18:03   ` Linus Torvalds
2018-02-16 22:32     ` John Ogness
2018-02-16 22:42       ` Linus Torvalds
2018-02-16 23:05         ` John Ogness
2018-02-16 23:31           ` Linus Torvalds
2018-02-16 23:49             ` John Ogness [this message]
2018-02-17  0:06               ` Linus Torvalds
2018-02-19 23:34                 ` John Ogness
2018-02-20  0:42                   ` Linus Torvalds
2018-02-20  8:39                   ` Peter Zijlstra
2018-02-20  8:43                     ` Peter Zijlstra
2018-02-22  5:29                   ` Al Viro
2018-02-22  5:40     ` Al Viro

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=87lgfs3374.fsf@linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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