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 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.