From: Robert Love <rml@novell.com>
To: John Hawkes <hawkes@tomahawk.engr.sgi.com>
Cc: linux-kernel@vger.kernel.org, John McCutchan <ttb@tentacle.dhs.org>
Subject: Re: 2.6.10-mm3 scaling problem with inotify
Date: Thu, 13 Jan 2005 19:49:18 -0500 [thread overview]
Message-ID: <1105663758.6027.215.camel@localhost> (raw)
In-Reply-To: <200501132356.j0DNujUY016224@tomahawk.engr.sgi.com>
On Thu, 2005-01-13 at 15:56 -0800, John Hawkes wrote:
> I believe I've encountered a scaling problem with the inotify code in
> 2.6.10-mm3.
>
> vfs_read() and vfs_write() (for example) do:
> dnotify_parent(dentry, DN_ACCESS);
> inotify_dentry_parent_queue_event(dentry,
> IN_ACCESS, 0, dentry->d_name.name);
> inotify_inode_queue_event(inode, IN_ACCESS, 0, NULL);
> for the optional "notify" functionality.
>
> dnotify_parent() knows how to exit quickly:
> if (!dir_notify_enable)
> return;
This isn't a "quick exit", though. It is just a termination check in
case dnotify was disabled on boot. The rest of dnotify_parent() is
always executed and it does the equivalent of dget_parent().
So why is inotify showing up on your test and not dnotify?
Hm, dnotify always grabs the lock but does not bump dentry->count unless
there is actually a watch on the dentry. Could that really be the
difference and cause of the slowdown? We could probably do that, too.
> Is it possible for a parent's inode->inotify_data to be enabled when none of
> its children's inotify_data are enabled? That would make it easy - just look
> at the current inode's inotify_data before walking back to the parent.
Unfortunately, no. There is no relationship between the parent and the
child inode's inotify_data structure. The best we can do is exactly
what dnotify does, actually, which is
spin_lock(&dentry->d_lock);
parent = dentry->d_parent;
if (parent->d_inode->i_dnotify_mask & event) {
dget(parent);
spin_unlock(&dentry->d_lock);
__inode_dir_notify(parent->d_inode, event);
dput(parent);
} else {
spin_unlock(&dentry->d_lock);
}
Instead of our current "explicit"
parent = dget_parent(dentry);
inotify_inode_queue_event(parent->d_inode, mask, cookie,
filename);
dput(parent);
E.g., save the ref unless absolutely needed.
I am open to other ideas, too, but I don't see any nice shortcuts like
what we can do in inotify_inode_queue_event().
(Other) John? Any ideas?
Best,
Robert Love
next prev parent reply other threads:[~2005-01-14 0:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-13 23:56 2.6.10-mm3 scaling problem with inotify John Hawkes
2005-01-14 0:49 ` Robert Love [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2005-01-14 0:51 John Hawkes
2005-01-14 2:31 Zou, Nanhai
2005-01-14 2:36 ` John McCutchan
2005-01-14 2:41 ` Robert Love
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=1105663758.6027.215.camel@localhost \
--to=rml@novell.com \
--cc=hawkes@tomahawk.engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ttb@tentacle.dhs.org \
/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