Re: mincore on anon mappings

[David S. Miller]

On Sat, 19 Jun 2004 18:25:03 +0200
Andrea Arcangeli <andrea@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/