Messages in this thread | | | Date | Fri, 20 Feb 2004 16:31:52 +0000 | From | Jamie Lokier <> | Subject | Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN |
| |
Ingo Molnar wrote: > 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.
Eh? Signals are queued, and the file descriptor number is stored in the siginfo.
> 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.
dnotify _should_ be quite low overhead, although not as low as your syscall of course. I've never measured it, nor looked much at the kernel code, but in principle delivering a siginfo through sigtimedwait() should be quite fast.
But I agree it's too much. Hence:
> > 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.
Yes yes, but I'm thinking of the _many_ other applications that aren't Samba and could benefit from a similar facility. Also, dnotify is there already - the signalling mechanism isn't pretty, but the hooks to catch directory changes are fine.
By the way, what is the scope of O_CLEAN? Does it fail if _any_ operation was done to the directory, or only if operations were done by non-Samba tasks? If the former, it has the same scalability problem that Linus mentioned: Samba shouldn't have to evict its cache when it creates files itself. If the latter, is the test process-wide, thread-wide, or CLONE_FILES-wide?
-- Jamie - 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/
| |