Messages in this thread | | | Date | Thu, 23 Feb 2006 16:14:25 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| |