This patch from over a month ago doesn't seem to have made it into kvm-73 and may have been lost in the shuffle. Attached is essentially the same patch but as applied to kvm-73, and validated relative to that version. In a nutshell the intention here is to allow preallocation of guest huge page backed memory at qemu initialization time to avoid a quirk in the kernel's huge page accounting allowing overcommit of huge pages. Failure of the kernel to resolve a guest fault to overcommitted huge page memory during runtime results in sigkill termination of the guest. This patch provides the option of avoiding such behavior at the cost of up-front preallocation of physical huge pages backing the guest. -john Anthony Liguori wrote: > john cooper wrote: >> Anthony Liguori wrote: >>> john cooper wrote: >>>> As it currently exists alloc_hpage_mem() is tied to >>>> the notion of huge page allocation as it will reference >>>> gethugepagesize() irrespective of *mem_path. So even >>>> in the case of tmpfs backed files, if the host kernel >>>> has been configured with CONFIG_HUGETLBFS we will wind >>>> up doing allocations of /dev/shm mapped files at >>>> /proc/meminfo:Hugepagesize granularity. >>> >>> Which is fine. It just means we round -m values up to even numbers. >> >> Well, yes it will round the allocation. But from a >> minimally sufficient 4KB boundary to that of 4MB/2MB >> relative to a 32/64 bit x86 host which is excessive. >> >>>> Probably not what was intended but probably not too >>>> much of a concern as "-mem-path /dev/shm" is likely >>>> only used in debug of this flag and associated logic. >>>> I don't see it currently being worth the trouble to >>>> correct from a squeaky clean POV, and doing so may >>>> drag in far more than the header file we've just >>>> booted above to deal with this architecture/config >>>> dependency. >>> >>> Renaming a function to a name that's less accurate seems bad to me. >>> I don't mean to be pedantic, but it seems like a strange thing to >>> do. I prefer it the way it was before. >> >> I don't see any harm reverting the name. But I do >> believe it is largely cosmetic as given the above, >> the current code does require some work to make it >> independent of huge page assumptions. Update attached. >> >> -john > > Looks good to me. > > Acked-by: Anthony Liguori > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- john.cooper@third-harmonic.com