Messages in this thread | | | Date | Thu, 30 Sep 2004 10:48:08 -0700 | From | Paul Jackson <> | Subject | Re: [RFC][PATCH] inotify 0.10.0 |
| |
Ray wrote: > However, dnotify has shown that forcing userspace to cache the > entire contents of all the directories it wishes to watch doesn't scale > well.
The dnotify cache isn't just an optional performance tweak, caching inode to name. It's an essential tracking of much of the stat information of any file of interest, in order to have _any_ way of detecting which file changed.
The inotify cache could just have the last few most recently used entries or some such - it's just a space vs time performance tradeoff.
So passing back an inode number doesn't come close to reintroducing the forced tracking of all the interesting stat data of every file.
> dnotify already forces an O(N) workload per directory onto > userspace, and that has shown itself to not work well.
Just because there exists an O(N) solution that has been shown to fail doesn't mean all O(N) solutions fail. If the constants change enough, then the actual numbers (how many changes per minute, how many compute cycles and memory bytes, what's the likely cache hit rate for a given size cache, ...) need to be re-examined. I see no evidence of that re-examination -- am I missing something?
> getdents(2) seems to work somehow.
Yeah ... but we had to walk up hill, both ways, through 9 foot snow drifts, for years, summer and winter, to get there ;).
> the kernel *has* that information already, ...
Frustrating, isn't it. The information is right there, and we're trying to keep you from getting to it.
Whatever ...
> Off to do honest work,
Good idea. Good luck with this. I rest my case, such as it be.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - 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/
| |