[lkml]   [2007]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: MADV_FREE functionality
    On Mon, 30 Apr 2007 20:54:02 -0400 Rik van Riel <> wrote:

    > 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
    > pages.
    > 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
    > memory
    > - 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
    > idea.

    OK, thanks. I stuck that in the changelog.

    Michael, do you think that's enough to finalise a manpage?

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

    The patch doesn't update the various comments in madvise.c at all, which is
    a surprise. Could you please check that they are all accurate and complete?

    Also, where did we end up with the Solaris compatibility?

    The patch I have at present retains MADV_FREE=0x05 for sparc and sparc64
    which should be good.

    Did we decide that the Solaris and Linux implementations of MADV_FREE are

    What about the Solaris and Linux MADV_DONTNEED implementations?
    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 03:21    [W:0.023 / U:5.668 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site