RE: 2.6.10-mm3 scaling problem with inotify

From: Zou, Nanhai
Date: Thu Jan 13 2005 - 21:34:37 EST


> -----Original Message-----
> From: Zou, Nanhai
> Sent: Friday, January 14, 2005 10:28 AM
> To: 'John McCutchan'
> Subject: RE: 2.6.10-mm3 scaling problem with inotify
>
> > From: linux-kernel-owner@xxxxxxxxxxxxxxx
> > [mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of John
McCutchan
> > Sent: Friday, January 14, 2005 9:31 AM
> > To: Robert Love
> > Cc: John Hawkes; linux-kernel@xxxxxxxxxxxxxxx
> > Subject: Re: 2.6.10-mm3 scaling problem with inotify
> >
> > On Thu, 2005-01-13 at 19:49 -0500, Robert Love wrote:
> > > On Thu, 2005-01-13 at 15:56 -0800, John Hawkes wrote:
> > > [snip]
> > >
> > > 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?
> >
> > No, you covered things well. This code was really just a straight
copy
> > of the dnotify code. Rob cleaned it up at some point, giving us what
we
> > have today. The only fix I can think of is the one suggested by Rob
--
> > copying the dnotify code again.


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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/