On Wed, 11 Jul 2018 21:12:54 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote: > On 11.07.2018 21:06, Christian Borntraeger wrote: > > > > > > On 07/11/2018 09:00 PM, David Hildenbrand wrote: > >> On 11.07.2018 17:07, frankja wrote: > >>> On Fri, 6 Jul 2018 16:52:50 +0200 > >>> David Hildenbrand <david@xxxxxxxxxx> wrote: > >>> > >>>> On 06.07.2018 15:55, Janosch Frank wrote: > >>>>> So, after the userfaultfd fix postcopy does work now, but vSIE > >>>>> in combination with paging can still result in crashing g3s. > >>>>> Therefore we split up the series and only integrate non-vSIE > >>>>> support for now. > >>>> > >>>> Just for the fun of it, did you try unlocking THP on a 4k guest > >>>> with the KVM huge page capability set? Should be fairly easy. > >>>> > >>>> My assumption is that it should be a pretty good sanity check if > >>>> all notifiers/invalidations are working :) > >>> > >>> After ripping out all of the safeguards, the guest boots and is > >>> successfully running memtester on 4g of its memory. > >>> > >>> The guest itself has 6gb: > >>> > >>> 3fdeff00000-3ff6ff00000 rw-p 00000000 00:00 0 > >>> Size: 6291456 kB > >>> KernelPageSize: 4 kB > >>> MMUPageSize: 4 kB > >>> Rss: 6291456 kB > >>> Pss: 6291456 kB > >>> Shared_Clean: 0 kB > >>> Shared_Dirty: 0 kB > >>> Private_Clean: 0 kB > >>> Private_Dirty: 6291456 kB > >>> Referenced: 6291456 kB > >>> Anonymous: 6291456 kB > >>> LazyFree: 0 kB > >>> AnonHugePages: 6266880 kB > >>> ShmemPmdMapped: 0 kB > >>> Shared_Hugetlb: 0 kB > >>> Private_Hugetlb: 0 kB > >>> Swap: 0 kB > >>> SwapPss: 0 kB > >>> Locked: 6291456 kB > >>> VmFlags: rd wr mr mw me dc ac dd hg mg > >>> > >> > >> Well that looks promising. Does it make sense to add that > >> "unlocking" as an addon patch right away? > > > > No, please no THP automatically as it is not always a win for KVM > > especially on older CPUs. We have now a minimum set of patches - > > lets keep it that way. > > > > For THP we need some more time and logic (e.g. only do it when > > MACHINE_HAS_TLB_GUEST is avalable as newer cpus do always > > benefit). > > Makes sense, but this would then be another kind of "automatic". > Wonder if the user should be able to configure this somehow (QEMU > option, KVM module parameter) ... hmmm ... THP has a lot of implicit consequences and is intertwined with hpage, I want to focus on fully enabling hpage and then we can add thp. It's not only about the unlocking, we also need to disable the same facilities as with hpage, so it's not really transparent at all currently. Currently QEMU always enables thp, so we'd always loose these facilities and I don't think that's acceptable. > > But good to know that the current implementation can deal with it, > another sign that we are not missing anything important. > Right, so let's finish this part for good. v6 is in preparation.
