On Wed, Oct 30, 2013 at 08:56:17PM +0100, Igor Mammedov wrote: > On Wed, 30 Oct 2013 16:51:29 -0200 > Marcelo Tosatti <mtosa...@redhat.com> wrote: > > > On Wed, Oct 30, 2013 at 05:49:49PM +0100, Igor Mammedov wrote: > > > On Tue, 29 Oct 2013 19:38:44 -0200 > > > Marcelo Tosatti <mtosa...@redhat.com> wrote: > > > > > > > On Tue, Oct 29, 2013 at 07:18:49PM +0100, Igor Mammedov wrote: > > > > > Otherwise 1GB TLBs cannot be cached for the range. > > > > > > > > This fails to back non-1GB-aligned gpas, but 2MB aligned, with 2MB large > > > > pages. > > > With current command line only one hugetlbfs mount point is possible, so > > > it > > > will back with whatever alignment specified hugetlbfs mount point has. > > > Anything that doesn't fit into page aligned region goes to tail using > > > non hugepage baked phys_mem_set_alloc()=qemu_anon_ram_alloc() allocator. > > > > The patch you propose allocates the non-1GB aligned tail of RAM with 4k > > pages. As mentioned, this is not acceptable (2MB pages should be used > > whenever 1GB alignment is not possible). > > > > I believe its easier for the user to allocate enough 1GB pages to back > > all of guest RAM, since allocation is static, than for him to allocate > > mixed 1GB/2MB pages in hugetlbfs. > tail, if it's present at all, is always less than 1Gb. > why tail allocated with 4K pages is not acceptable?
Depends on workload. > btw: now if QEMU can't allocate hugepages for whole guest size it will > fallback > to 4k pages anyway for whole guest size, with warning that isn't visible if > user doesn't start QEMU manually. Not with -mem-prealloc.
