Re: [RFC][PATCH] inotify 0.10.0
From: Paul Jackson
Date: Thu Sep 30 2004 - 12:53:15 EST
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@xxxxxxx> 1.650.933.1373
-
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/