lkml.org 
[lkml]   [2007]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 36/42] VFS: export drop_pagecache_sb
    Date
    On Friday 14 December 2007 02:24, Erez Zadok wrote:
    > In message <200712121638.35167.nickpiggin@yahoo.com.au>, Nick Piggin writes:
    > > On Monday 10 December 2007 13:42, Erez Zadok wrote:
    > > > Needed to maintain cache coherency after branch management.
    > >
    > > Hmm, I'd much prefer to be able to sleep in invalidate_mapping_pages
    > > before this function gets exported.
    > >
    > > As it is, it can cause massive latencies on preemption and the inode_lock
    > > so it is pretty much debug-only IMO. I'd rather it didn't escape into the
    > > wild as is.
    > >
    > > Either that or rework your cache coherency somehow.
    >
    > Nick, thanks for the advice.
    >
    > We use a generation number after each successful branch configuration
    > command, so that ->d_revalidate later on can discover that change, and
    > rebuild the union of objects. At ->remount time, I figured it'd be nice to
    > "encourage" that revalidation to happen sooner, by invalidating as many
    > upper pages as possible, thus causing ->d_revalidate/->readpage to take
    > place sooner. So we used to call drop_pagecache_sb from our remount code:
    > it was the only caller of drop_pagecache_sb. It wasn't too much of an
    > latency issue to call drop_pagecache_sb there: the VFS remount code path is
    > already pretty slow (dropping temporarily to readonly mode, and dropping
    > other caches), and remount isn't an operation used often, so a little bit
    > more latency would probably not have been noticed by users.

    Well a large, infrequent spike is the most damaging to latency sensitive
    users. And anyway, I guess the infrequency of remount means it doesn't
    have to be really efficient with invalidating pagecache either.


    > Nevertheless, it was not strictly necessary to call drop_pagecache_sb in
    > unionfs_remount, because the objects in question will have gotten
    > revalidated sooner or later anyway; the call to drop_pagecache_sb was just
    > an optimization (one which I wasn't 100% sure about anyway, as per my long
    > "XXX" comment above that call in unionfs_remount).
    >
    > So I agree with you: if this symbol can be abused by modules and cause
    > problems, then exporting it to modules is too risky. I've reworked my code
    > to avoid calling drop_pagecache_sb and I'll [sic] drop that patch.

    Thanks, I'd be much happier with that.


    \
     
     \ /
      Last update: 2007-12-13 23:53    [W:3.055 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site