On Fri, 2018-04-27 at 12:14 +1000, David Gibson wrote: > On Thu, Apr 26, 2018 at 10:45:40AM +0200, Andrea Bolognani wrote: > > Unfortunately, that pretty much seals the deal on libvirt *not* being > > able to infer the value from other guest settings :( > > > > The only reasonable candidate would be the size of host pages used for > > backing guest memory; however > > Right. > > > * TCG, RPT and KVM PR guests can't infer anything from it, as they > > are not tied to it. Having different behaviors for TCG and KVM > > would be easy, but differentiating between HPT KVM HV guest and > > all other kinds is something we can't do at the moment, and that > > in the past have actively resisted doing; > > Yeah, I certainly wouldn't recommend that. It's basically what we're > doing in qemu now, and I want to change, because it's a bad idea. > > It still would be possible to key off the host side hugepage size, but > apply the limit to all VMs - in a sense crippling TCG guests to give > them matching behaviour to KVM guests.
As you yourself mention later... > > * the user might want to limit things further, eg. preventing an > > HPT KVM HV guest backed by 16 MiB pages or an HPT TCG guest from > > using hugepages. > > Right.. note that with the draft qemu patches a TCG guest will be > prevented from using hugepages *by default* (the default value of the > capability is 16). You have to explicitly change it to allow > hugepages to be used in a TCG guest (but you don't have to supply > hugepage backing). ... this will already happen. That's okay[1], we can't really avoid it if we want to ensure consistent behavior between KVM and TCG. > > With the second use case in mind: would it make sense, or even be > > possible, to make it so the capability works for RPT guests too? > > Possible, maybe.. I think there's another property where RPT pagesizes > are advertised. But I think it's a bad idea. In order to have the > normal HPT case work consistently we need to set the default cap value > to 16 (64kiB page max). If that applied to RPT guests as well, we'd > be unnecessarily crippling nearly all RPT guests. > > > Thinking even further, what about other architectures? Is this > > something they might want to do too? The scenario I have in mind is > > guests backed by regular pages being prevented from using hugepages > > with the rationale that they wouldn't have the same performance > > characteristics as if they were backed by hugepages; on the opposite > > side of the spectrum, you might want to ensure the pages used to > > back guest memory are as big as the biggest page you plan to use in > > the guest, in order to guarantee the performance characteristics > > fully match expectations. > > Hm, well, you'd have to ask other arch people if they see a use for > that. It doesn't look very useful to me. I don't think libvirt can > or should ensure identical performance characteristics for a guest > across all possible migrations. But for HPT guests, it's not a matter > of performance characteristics: if it tries to use a large page size > and KVM doesn't have large enough backing pages, the guest will > quickly just freeze on a page fault that can never be satisfied. I realize only HPT guests *need* this, but I was trying to figure out whether giving the host administrator more control over the guest page size could be a useful feature in other cases as well, as it sounds to me like it's more generally applicable Users already need to opt-in to using hugepages in the host; asking to opt-in to guest hugepages support as well doesn't seem too outlandish to me. Even if the specific flags required vary between architectures, we could expose this in a unified fashion in libvirt. However, if this is not something people would consider useful, we can just have a pSeries-specific setting instead. [1] That's of course assuming you have made sure the restriction only applies to the 2.13 machine type forward, and existing guests are not affected by the change. -- Andrea Bolognani / Red Hat / Virtualization