lkml.org 
[lkml]   [2006]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: udevd is killing file write performance.
John McCutchan <john@johnmccutchan.com> wrote:
>
> > > @@ -538,7 +537,7 @@
> > > struct dentry *parent;
> > > struct inode *inode;
> > >
> > > - if (!atomic_read (&inotify_watches))
> > > + if (!atomic_read (&dentry->d_sb->s_inotify_watches))
> > > return;
> > >
> >
> > What happens here if we're watching a mountpoint - the parent is on a
> > different fs?
>
> There are four cases to consider here.
>
> Case 1: parent fs watched and child fs watched
> correct results
> Case 2: parent fs watched and child fs not watched
> We may not deliver an event that should be delivered.
> Case 3: parent fs not watched and child fs watched
> We take d_lock when we don't need to
> Case 4: parent fs not watched and child fs not watched
> correct results
>
> Case 2 screws us. We have to take the lock to even look at the parent's
> dentry->d_sb->s_inotify_watches. I don't know of a way around this one.

Yeah. There are a lot of "screw"s in this thread.

I wonder if RCU can save us - if we do an rcu_read_lock() we at least know
that the dentries won't get deallocated. Then we can take a look at
d_parent (which might not be the parent any more). Once in a million years
we might send a false event or miss sending an event, depending on where
our dentry suddenly got moved to. Not very nice, but at least it won't
oops.

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

\
 
 \ /
  Last update: 2006-02-24 07:05    [W:0.562 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site