Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN

Jamie Lokier
2004-02-21T03:01:28Z

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