[lkml]   [2007]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectMADV_FREE functionality
    Andrew Morton wrote:

    > lazy-freeing-of-memory-through-madv_free.patch
    > lazy-freeing-of-memory-through-madv_free-vs-mm-madvise-avoid-exclusive-mmap_sem.patch
    > restore-madv_dontneed-to-its-original-linux-behaviour.patch
    > I think the MADV_FREE changes need more work:
    > We need crystal-clear statements regarding the present functionality, the new
    > functionality and how these relate to the spec and to implmentations in other
    > OS'es. Once we have that info we are in a position to work out whether the
    > code can be merged as-is, or if additional changes are needed.

    There are two MADV variants that free pages, both do the exact
    same thing with mapped file pages, but both do something slightly
    different with anonymous pages.

    MADV_DONTNEED will unmap file pages and free anonymous pages.
    When a process accesses anonymous memory at an address that
    was zapped with MADV_DONTNEED, it will return fresh zero filled

    MADV_FREE will unmap file pages. MADV_FREE on anonymous pages
    is interpreted as a signal that the application no longer needs
    the data in the pages, and they can be thrown away if the kernel
    needs the memory for something else. However, if the process
    accesses the memory again before the kernel needs it, the process
    will simply get the original pages back. If the kernel needed
    the memory first, the process will get a fresh zero filled page
    like with MADV_DONTNEED.

    In short:
    - both MADV_FREE and MADV_DONTNEED only unmap file pages
    - after MADV_DONTNEED the application will always get back
    fresh zero filled anonymous pages when accessing the
    - after MADV_FREE the application can either get back the
    original data (without a page fault) or zero filled
    anonymous memory

    The Linux MADV_DONTNEED behavior is not POSIX compliant.
    POSIX says that with MADV_DONTNEED the application's data
    will be preserved.

    Currently glibc simply ignores POSIX_MADV_DONTNEED requests
    from applications on Linux. Changing the behaviour which
    some Linux applications may rely on might not be the best

    If you want POSIX_MADV_DONTNEED behaviour added, please let
    me know and I'll whip up a patch.

    > Because right now, I don't know where we are with respect to these things and
    > I doubt if many of our users know either. How can Michael write a manpage for
    > this is we don't tell him what it all does?

    If you need any additional information, please let me know.

    If you still think the MADV_FREE patches themselves should
    not be merged yet, can we at least merge the #defines, so
    the Fedora kernel can get the MADV_FREE functionality?

    Again, I'd be more than willing to whip up a patch for that.

    Politics is the struggle between those who want to make their country
    the best in the world, and those who believe it already is. Each group
    calls the other unpatriotic.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-01 02:57    [W:0.023 / U:165.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site