Messages in this thread | | | Subject | Re: differences between MADV_FREE and MADV_DONTNEED | From | (Eric W. Biederman) | Date | Tue, 17 Jan 2006 11:23:53 -0700 |
| |
Christoph Hellwig <hch@infradead.org> writes:
> On Mon, Jan 16, 2006 at 05:04:07PM -0800, Nicholas Miell wrote: >> On Mon, 2006-01-16 at 16:24 -0800, Suleiman Souhlal wrote: >> > Eric W. Biederman wrote: >> > > As I recall the logic with DONTNEED was to mark the mapping of >> > > the page clean so the page didn't need to be swapped out, it could >> > > just be dropped. >> > > >> > > That is why they anonymous and the file backed cases differ. >> > > >> > > Part of the point is to avoid the case of swapping the pages out if >> > > the application doesn't care what is on them anymore. >> > >> > Well, imho, MADV_DONTNEED should mean "I won't need this anytime soon", >> > and MADV_FREE "I will never need this again". >> > >> >> POSIX doesn't have a madvise(), but it does have a posix_madvise(), with >> flags defined as follows: >> >> POSIX_MADV_NORMAL >> Specifies that the application has no advice to give on its behavior >> with respect to the specified range. It is the default characteristic if >> no advice is given for a range of memory. >> POSIX_MADV_SEQUENTIAL >> Specifies that the application expects to access the specified range >> sequentially from lower addresses to higher addresses. >> POSIX_MADV_RANDOM >> Specifies that the application expects to access the specified range >> in a random order. >> POSIX_MADV_WILLNEED >> Specifies that the application expects to access the specified range >> in the near future. >> POSIX_MADV_DONTNEED >> Specifies that the application expects that it will not access the >> specified range in the near future. >> >> Note that glibc forwards posix_madvise() directly to madvise(2), which >> means that right now, POSIX conformant apps which use >> posix_madvise(addr, len, POSIX_MADV_DONTNEED) are silently corrupting >> data on Linux systems. > > Does our MAD_DONTNEED numerical value match glibc's POSIX_MADV_DONTNEED? > > In either case I'd say we should backout this patch for now. We should > implement a real MADV_DONTNEED and rename the current one to MADV_FREE, > but that's 2.6.17 material.
We definitely need to check this. I am fairly certain I have seen this conversation before.
Eric
- 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/
| |