Messages in this thread | | | Date | Wed, 04 Apr 2007 18:47:08 +1000 | From | Nick Piggin <> | Subject | Re: missing madvise functionality |
| |
Jakub Jelinek wrote: > On Wed, Apr 04, 2007 at 05:46:12PM +1000, Nick Piggin wrote: > >>Does mmap(PROT_NONE) actually free the memory? > > > Yes. > /* Clear old maps */ > error = -ENOMEM; > munmap_back: > vma = find_vma_prepare(mm, addr, &prev, &rb_link, &rb_parent); > if (vma && vma->vm_start < addr + len) { > if (do_munmap(mm, addr, len)) > return -ENOMEM; > goto munmap_back; > }
Thanks, I overlooked the mmap vs mprotect detail. So how are the subsequent access faults avoided?
>>In the case of pages being unused then almost immediately reused, why is >>it a bad solution to avoid freeing? Is it that you want to avoid >>heuristics because in some cases they could fail and end up using memory? > > > free(3) doesn't know if the memory will be reused soon, late or never. > So avoiding trimming could substantially increase memory consumption with > certain malloc/free patterns, especially in threaded programs that use > multiple arenas. Implementing some sort of deferred memory trimming > in malloc is "solving" the problem in a wrong place, each app really has no > idea (and should not have) what the current system memory pressure is.
Thanks for the clarification.
>>Secondly, why is MADV_DONTNEED bad? How much more expensive is a pagefault >>than a syscall? (including the cost of the TLB fill for the memory access >>after the syscall, of course). > > > That's page fault per page rather than a syscall for the whole chunk, > furthermore zeroing is expensive.
Ah, for big allocations. OK, we could make a MADV_POPULATE to prefault pages (like mmap's MAP_POPULATE, but without the down_write(mmap_sem)).
If you're just about to use the pages anyway, how much of a win would it be to avoid zeroing? We allocate cache hot pages for these guys...
-- SUSE Labs, Novell Inc. - 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/
| |