On Tue, 23 Aug 2005, Ulrich Drepper wrote: > > One possible solution would be to add a flag to mremap() which allows > mremap() to steal memory. In general that would be too dangerous but we > could limit it to private, anonymous mappings which have no access > permissions (i.e., PROT_NONE with MAP_PRIVATE and MAP_ANON). One > explicitly has to allocate such blocks, they don't appear naturally. > And the program in any case knows about the address space layout. > > So, how about adding MREMAP_MAPOVERNONE or so?
If the app can plan ahead as you're proposing, why doesn't it just mmap the maximum it might need, mprotect PROT_NONE the end it doesn't need yet, then progressively re-mprotect parts to make them accessible as needed? I'm missing what mremap gives you here that mprotect doesn't. Though I do see that it would be nice not to be forced into mremap moving all the time, because of other maps blocking you off: nice perhaps to know what region of the layout is least likely to be so affected. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/