lkml.org 
[lkml]   [2004]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:4.168 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site