Messages in this thread | | | Date | Fri, 20 Feb 2004 14:37:07 +0100 | From | Ingo Molnar <> | Subject | Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN |
| |
* Jamie Lokier <jamie@shareable.org> wrote:
> > - it's a synchronous solution that avoids signals, and is thus > > usable/robust in libraries too. > > I do like the robustness, due to the way the flag is associated with > dirfd. > > > - dnotify _forces_ action. mark_dir_clean() you can use if there's use > > and there's no overhead if the Samba workload is completely silent > > and there are only POSIX users. I.e. it should scale better than > > dnotify. > > Firstly, it doesn't scale better than dnotify in this scenario if > you're using signals and one-shot mode. With one-shot mode, there's > also no overhead if there are only POSIX users.
the overriding argument is that the bit needs to be maintained by Samba expliticly - i.e. no way around sys_mark_dir_clean() and O_CLEAN. And if we've done that it costs us _nothing_ to return the previous bit value in sys_mark_dir_clean() - which Samba can use to build a 100% coherent name cache. At which point i can see no reason at all to use any variant of dnotify/select/poll/epoll.
Also, one-shot mode will make you lose multiple outstanding events from multiple directories, unless you associate separate signals with each directory watched - which will make you run out of the 64 signals very quick.
> Secondly, dnotify is synchronous if you _block_ the dnotify signal and > use sigtimedwait() to collect events.
it still queues up kernel structures (dnotify event structures and signal structures) which can get lost or can overflow, etc. The 'clean bit' has no such queueing problem.
> I'd personally like to see the robustness problem solved with epoll or > something similar extended to queue more general events to userspace, > more reliably.
why? A synchronous lookup is just that - a synchronous lookup. There's no need at all for Samba to know about all namespace activities. What it wants to have is coherency between its own cache and the VFS.
dnotify (or epoll) is useful for applications that need to know about all events: eg. directory visualisation apps. For everything else (like Samba) it's too much overhead i believe.
> Hey! That's an idea: Use select/poll on the dirfd to read this bit. > That gives you the flexibility to wait, or collect events from > multiple directories. (Philosophicaly, every event should be > accessible through select/poll/epoll, right?).
Samba doesnt want to 'wait' for any event. It just wants to keep in sync with the VFS in a minimalistic way: update the cache only when absolutely necessary. Think of it as a CPU's cache validation protocol - you dont want to re-read invalid cachelines all the time, only if they are really needed.
Ingo - 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/
| |