Messages in this thread | | | Date | Sat, 19 Jun 2004 11:54:11 -0700 | From | "David S. Miller" <> | Subject | Re: mincore on anon mappings |
| |
On Sat, 19 Jun 2004 18:25:03 +0200 Andrea Arcangeli <andrea@suse.de> wrote:
> here a first (untested) attempt to allow mincore on anon vmas too. > > I heard you need this from gcc, right?
Sort of. What I think we really need is a new MAP_FIXED that doesn't wipe out existing mappings.
The issue is that architectures make decisions about passed in "hint" addresses based upon cache aliasing concerns sometimes.
You can bypass that by using MAP_FIXED, but MAP_FIXED has the nasty side effect of zapping existing mappings. That's not what the user wants in this case, the user here wants to tell the cache aliasing virtual address hint changing logic to just go away.
mincore() is a really inefficient way to accomplish what GCC wants. What gcc would do with this is basically:
addr = mmap(request_address, ..., len, ...); if (addr == MMAP_FAIL) { use_mincore_to_see_if_area_free(request_address, len); if (really_is_free) addr = mmap( ... | MAP_FIXED ); }
See? That's terribly inefficient.
Basically what GCC is trying to do is mmap a file at a fixed location. Per-architecture get_unmapped_area() implementations will change the requested address, unless MAP_FIXED is set, in order to more efficiently handle cache aliasing issues in data caches. Using MAP_FIXED has the unwanted side-effect of munmap()'ing any existing things in that range, which is not what GCC wants.
Therefore I propose we add a MAP_FORCE which does exactly what GCC wants which is:
1) The passed in 'hint' address is treated as mandatory, if exactly that address cannot be used, we fail.
2) Existing areas get in the way, and cause failure.
3) get_unmapped_area() implementations shut off any 'hint' address modification logic they may have.
I think the mincore() fix is important independant of how GCC eventually deals with the thing it wants to accomplish. - 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/
| |