Messages in this thread | | | Date | Mon, 30 Apr 2007 18:18:39 -0700 | From | Andrew Morton <> | Subject | Re: MADV_FREE functionality |
| |
On Mon, 30 Apr 2007 20:54:02 -0400 Rik van Riel <riel@redhat.com> 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 compatible?
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 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/
| |