[lkml]   [2012]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE flags
    On Tue, 14 Feb 2012 16:29:10 -0800 John Stultz <> wrote:

    > But I'm open to other ideas and arguments.

    I didn't notice the original patch, but found it at
    and had a look.

    My first comment is -ENODOC. A bit background always helps, so let me try to
    construct that:

    The goal is to allow applications to interact with the kernel's cache
    management infrastructure. In particular an application can say "this
    memory contains data that might be useful in the future, but can be
    reconstructed if necessary, and it is cheaper to reconstruct it than to read
    it back from disk, so don't bother writing it out".

    The proposed mechanism - at a high level - is for user-space to be able to
    say "This memory is volatile" and then later "this memory is no longer
    volatile". If the content of the memory is still available the second
    request succeeds. If not, it fails.. Well, actually it succeeds but reports
    that some content has been lost. (not sure what happens then - can the app do
    a binary search to find which pages it still has or something).

    (technically we should probably include the cost to reconstruct the page,
    which the kernel measures as 'seeks' but maybe that isn't necessary).

    This is implemented by using files in a 'tmpfs' filesystem. These file
    support three new flags to fadvise:

    POSIX_FADV_VOLATILE - this marks a range of pages as 'volatile'. They may be
    removed from the page cache as needed, even if they are not 'clean'.
    POSIX_FADV_NONVOLATILE - this marks a range of pages as non-volatile.
    If any pages in the range were previously volatile but have since been
    removed, then a status is returned reporting this.
    POSIX_FADV_ISVOLATILE - this does not actually give any advice to the kernel
    but rather asks a question: Are any of these pages volatile?

    Is this an accurate description?

    My first thoughts are:
    1/ is page granularity really needed? Would file granularity be sufficient?
    2/ POSIX_FADV_ISVOLATILE is a warning sign to me - it doesn't actually
    provide advice. Is this really needed? What for? Because it feels like
    a wrong interface.
    3/ Given that this is specific to one filesystem, is fadvise really an
    appropriate interface?

    (fleshing out the above documentation might be an excellent way to answer
    these questions).

    As a counter-point, this is my first thought of an implementation approach
    (-ENOPATCH, sorry)

    - new mount option for tmpfs e.g. 'volatile'. Any file in a filesystem
    mounted with that option and which is not currently open by any process can
    have blocks removed at any time. The file name must remain, and the file
    size must not change.
    - lseek can be used to determine if anything has been purged with 'SEEK_DATA'
    and 'SEEK_HOLE'.

    So you can only mark volatility on a whole-file granularity (hence the
    question above).
    'open' says "NONVOLATILE".
    'close' says "VOLATILE".
    'lseek' is used to check if anything was discarded.

    This approach would allow multiple processes to share a cache (might this be
    valuable?) as it doesn't become truly volatile until all processes close
    their handles.

    Just a few thoughts ... take or discard as you choose.


    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2012-02-15 02:41    [W:0.032 / U:10.288 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site