Messages in this thread | | | Date | Sat, 21 Feb 2004 03:01:18 +0000 | From | Jamie Lokier <> | Subject | Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN |
| |
Linus Torvalds wrote: > That's what Ingo's O_CLEAN thing did. An di fyou do Ingo's O_CLEAN, then > there's no point to notifiers in the first place - Ingo's algorithm works > regardless of them (it had other problems, but that's another issue and > just requires a bit of extending on the basic concept). > > So why do you care about dnotify? It doesn't help at all once you have > O_CLEAN (or equivalent).
Please look at my pseudo-code carefully. It uses dnotify to test-and-set the bit; there isn't a "notify" event.
In other words, I'm making dnotify simpler by getting rid of the signal, so it becomes exactly the same as Ingo's syscall:
while (sys_mark_dir_clean(dirfd) == 0) { do_readdir(dirfd); } /* use results */
becomes:
while (fcntl(dirfd, F_NOTIFY, DN_CREATE|DN_RENAME|DN_DELETE|DN_NOSIGNAL) != 0) { do_readdir(dirfd); } /* use results */
In my scheme, we still have O_CLEAN. (Have I said that's a great idea enough times yet?)
The reason I prefer to add DN_NOSIGNAL to dnotify instead of a new syscall should be obvious: it's a simple change, equally fast, and dnotify is a _lot_ more versatile.
For Samba, dnotify lets you be more selective for various cache types, and poll() can do multiple tests in a single syscall - good for path walk algorithms (although I've shown in another email how the tests can be elided completely).
The combination of O_CLEAN with dnotify is useful for many other applications. I don't want to complicate this explanation by describing them. The dnotify change by itself is also good.
In short, it's a good thing, with no bad sides.
-- 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/
| |