This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/3458] posix_madvise(addr, len, POSIX_MADV_DONTNEED) discards data
- From: "nmiell at comcast dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 17 Feb 2007 20:35:46 -0000
- Subject: [Bug libc/3458] posix_madvise(addr, len, POSIX_MADV_DONTNEED) discards data
- References: <20061104102854.3458.nmiell@comcast.net>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From nmiell at comcast dot net 2007-02-17 20:35 -------
The second part of the description comes from the man-pages manual of madvise(2).
The kernel comment is as follows (from linux/mm/madvise.c):
/*
* Application no longer needs these pages. If the pages are dirty,
* it's OK to just throw them away. The app will be more careful about
* data it wants to keep. Be sure to free swap resources too. The
* zap_page_range call sets things up for refill_inactive to actually free
* these pages later if no one else has touched them in the meantime,
* although we could add these pages to a global reuse list for
* refill_inactive to pick up before reclaiming other pages.
*
* NB: This interface discards data rather than pushes it out to swap,
* as some implementations do. This has performance implications for
* applications like large transactional databases which want to discard
* pages in anonymous maps after committing to backing store the data
* that was kept in them. There is no reason to write this data out to
* the swap area if the application is discarding it.
*
* An interface that causes the system to free clean pages and flush
* dirty pages is already available as msync(MS_INVALIDATE).
*/
static long madvise_dontneed(struct vm_area_struct * vma,
struct vm_area_struct ** prev,
unsigned long start, unsigned long end)
and my reading of the implementation of madvise_dontneed() is that the comment
is accurate.
I have no knowledge of any lkml discussions, but my quick search turned up
http://lkml.org/lkml/2006/1/16/105 -- which doesn't seem to have gone anywhere.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3458
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.