From: John McCutchan <ttb@tentacle.dhs.org>
To: "Zou, Nanhai" <nanhai.zou@intel.com>
Cc: linux-kernel@vger.kernel.org, Robert Love <rml@novell.com>,
hawkes@tomahawk.engr.sgi.com
Subject: RE: 2.6.10-mm3 scaling problem with inotify
Date: Thu, 13 Jan 2005 21:36:20 -0500 [thread overview]
Message-ID: <1105670180.25359.2.camel@vertex> (raw)
In-Reply-To: <894E37DECA393E4D9374E0ACBBE7427013CA7E@pdsmsx402.ccr.corp.intel.com>
On Fri, 2005-01-14 at 10:31 +0800, Zou, Nanhai wrote:
>
> There is still a little difference between your implement in
> inotify_dentry_parent_queue_event from dnotify_parent
>
> In dnotify_parent, if parent is not watching the event, the code will
> not fall
> through dget and dput path.
>
> While in inotify_dentry_parent_queue_event kernel will go dget and dput
> even
> if (inode->inotify_data == NULL).
>
> While dget and dput will introduce a lot of atomic operations..
> And the most important, dput will grab global dcache_lock...,
> I think that is the reason why John Hawkes saw great performance drop.
>
> Simply follow dnotify_parent, only call dget and dput when
> inode->inotify_data != NULL will solve this problem I think.
>
Yeah, the old code was written before inode->inotify_data existed.
Robert caught this before he sent his patch. His patch should fix this
regression.
--
John McCutchan <ttb@tentacle.dhs.org>
next prev parent reply other threads:[~2005-01-14 2:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-14 2:31 2.6.10-mm3 scaling problem with inotify Zou, Nanhai
2005-01-14 2:36 ` John McCutchan [this message]
2005-01-14 2:41 ` Robert Love
-- strict thread matches above, loose matches on Subject: below --
2005-01-14 0:51 John Hawkes
2005-01-13 23:56 John Hawkes
2005-01-14 0:49 ` Robert Love
2005-01-14 1:31 ` John McCutchan
2005-01-14 2:29 ` Robert Love
2005-01-14 18:05 ` John Hawkes
2005-01-14 18:15 ` Robert Love
2005-01-14 18:39 ` John Hawkes
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=1105670180.25359.2.camel@vertex \
--to=ttb@tentacle.dhs.org \
--cc=hawkes@tomahawk.engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nanhai.zou@intel.com \
--cc=rml@novell.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.