On 14.02.2018 13:56, David Hildenbrand wrote: > On 14.02.2018 12:51, Paolo Bonzini wrote: >> On 13/02/2018 18:08, David Hildenbrand wrote: >>> On 13.02.2018 18:02, David Hildenbrand wrote: >>>> On 13.02.2018 17:44, Paolo Bonzini wrote: >>>>> On 13/02/2018 17:26, Christian Borntraeger wrote: >>>>>>> The test takes fairly long, especially because we only have 128MB of ram >>>>>>> and allocate 3 times in a row ~100mb of virtual memory. >>>>>> >>>>>> Does it make sense to change the memory size in the unittests.cfg file? e.g. via extra_params? >>>>> >>>>> The test takes 5 seconds on x86 KVM and about a minute on TCG (lots of >>>>> TLB misses). Maybe it's an s390-specific bug in the test? >>>> >>>> Under TCG: 1m 6,823s >>>> >>>> I have to idea how long it takes under LPAR. Right now, I only have a >>>> z/VM based system available, so we are already using nested >>>> virtualization (implemented by z/VM). I expect things to be slow :) >>>> >>>> Will try to find a LPAR to test with ... >>>> >>> >>> LPAR: 0m 6.552s >>> z/VM: > 6m >>> >>> So I don't think its a BUG. It's really nested virtualization kicking in. >> >> Whoa. How does KVM-on-KVM-on-LPAR fare? > > We do a lot of IPTE calls, which flush the TLB on all CPUs. > > But I think this could also be because the z/VM machine I am running on > is simply overloaded. But of course also because our nested virt > implementation in KVM is better ;) Just double checked, as we are not reusing virtual addresses, we are not issuing any IPTE instructions right now. So also no TLB flushes. This makes it very strange why z/VM performs (for me reproducible) that bad. > > Just tried nested under KVM (KVM-on-KVM-on-LPAR): > > real 0m 9.411s > >> >> I'll change the comment to >> >> # can take fairly long when KVM is nested inside z/VM >> >> Thanks, >> >> Paolo >> > > -- Thanks, David / dhildenb
