On Sat, Mar 13, 2010 at 10:28:32AM +0200, Avi Kivity wrote: > On 03/11/2010 06:05 PM, Andrea Arcangeli wrote: > > On Thu, Mar 11, 2010 at 05:52:16PM +0200, Avi Kivity wrote: > > > >> That is a little wasteful. How about a hint to mmap() requesting proper > >> alignment (MAP_HPAGE_ALIGN)? > >> > > So you suggest adding a new kernel feature to mmap? Not sure if it's > > worth it, considering it'd also increase the number of vmas because it > > will have to leave an hole. Wasting 2M-4k of virtual memory is likely > > cheaper than having 1 more vma in the rbtree for every page fault. So > > I think it's better to just malloc and adjust ourselfs on the next > > offset which is done in userland by qemu_memalign I think. > > > > > > Won't we get a new vma anyway due to the madvise() call later?
As long as MADV_HUGEPAGE is set in all, it will merge the vmas together. So if we do stuff like "alloc from 0 to 4G-4k" and then alloc "4G to 8G" this will avoid a vma split. (initially the mmap will create a vma, but it'll be immediately removed from madvise with vma_merge) > But I agree it isn't worth it. 2 vma or 1 vma isn't measurable of course, but yes the point is that it's not worth it because doing it in userland is theoretically better too for performance.
