lkml.org 
[lkml]   [2006]   [Feb]   [23]   [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:
>
> ...
> >
> > I have a bad feeling about this one. It'd be nice to have an exact
> > understanding of the problen source, but if it's just lots of traffic on
> > ->d_lock we're kinda stuck. I don't expect we'll run off and RCUify
> > d_parent or turn d_lock into a seq_lock or anything liek that.
> >
> > Then again, maybe making d_lock an rwlock _will_ help - if this workload is
> > also hitting tree_lock (Robin?) and we're not seeing suckiness due to that
> > then perhaps the rwlock is magically helping.
> >
> >
> > > instead of your hack.
> >
> > It's not a terribly bad hack - it's just poor-man's hashing, and it's
> > reasonably well-suited to the sorts of machines and workloads which we
> > expect will hit this problem.
> >
>
> If this is as good as it gets, here is a patch (totally untested).
>
> ...
> @@ -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?
-
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 01:18    [W:0.096 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site