Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)

[Andrea Bolognani]

On Tue, 2016-12-20 at 10:47 +1100, David Gibson wrote:
> > Do we want to expose a knob for controlling this
> > to the user at the libvirt level, or should we just enable
> > resize-hpt unconditionally whenever we detect that the QEMU
> > binary supports it?
> 
> I'm not sure if we need a knob.  I think in general enabling for
> pseries-2.9 and later machine types is correct.  The difficulty is
> that for HV guests, we can only enable it if the host kernel also has
> support.  Explicitly setting "resize-hpt=enable" means qemu will not
> start if the kernel doesn't support it.

I thought that would be the case for resize-hpt=required,
not resized-hpt=enabled.

> My inclination would be to enable unconditionally for pseries-2.9 and
> later machine types.

So I guess the question is, will users want to enable this
manually for older machine types, or is it reasonable to
expect them to simply switch to pseries-2.9 if they want
the feature?

Moreover, do you foresee any situation in which users
might reasonably want to turn the feature off even though
the entire stack (host kernel, QEMU, guest kernel)
understands it?

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2084 bytes --]

On Tue, Dec 20, 2016 at 10:19:21AM +0100, Andrea Bolognani wrote:
> On Tue, 2016-12-20 at 10:47 +1100, David Gibson wrote:
> > > Do we want to expose a knob for controlling this
> > > to the user at the libvirt level, or should we just enable
> > > resize-hpt unconditionally whenever we detect that the QEMU
> > > binary supports it?
> > 
> > I'm not sure if we need a knob.  I think in general enabling for
> > pseries-2.9 and later machine types is correct.  The difficulty is
> > that for HV guests, we can only enable it if the host kernel also has
> > support.  Explicitly setting "resize-hpt=enable" means qemu will not
> > start if the kernel doesn't support it.
> 
> I thought that would be the case for resize-hpt=required,
> not resized-hpt=enabled.

resize-hpt=enabled requires the host to support resizing, but not the
guest.  resize-hpt=required requires both the host and the guest to
support resizing.

If you can think of a less ambiguous word for it, let me know.

> > My inclination would be to enable unconditionally for pseries-2.9 and
> > later machine types.
> 
> So I guess the question is, will users want to enable this
> manually for older machine types, or is it reasonable to
> expect them to simply switch to pseries-2.9 if they want
> the feature?

I can't see any particular reason you'd enable it on an old machine
type.

> Moreover, do you foresee any situation in which users
> might reasonably want to turn the feature off even though
> the entire stack (host kernel, QEMU, guest kernel)
> understands it?

Nothing clearly compelling.  In the nearish term, being able to turn
it off to isolate possible bugs could be useful of course.  It's also
possible that you could have a VM where the latency of each resize
could be too much downtime - although in that case I doubt you'd want
to hotplug memory anyway.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)

[Andrea Bolognani]

On Wed, 2016-12-21 at 15:52 +1100, David Gibson wrote:
> > > I'm not sure if we need a knob.  I think in general enabling for
> > > pseries-2.9 and later machine types is correct.  The difficulty is
> > > that for HV guests, we can only enable it if the host kernel also has
> > > support.  Explicitly setting "resize-hpt=enable" means qemu will not
> > > start if the kernel doesn't support it.
> > 
> > I thought that would be the case for resize-hpt=required,
> > not resized-hpt=enabled.
> 
> resize-hpt=enabled requires the host to support resizing, but not the
> guest.  resize-hpt=required requires both the host and the guest to
> support resizing.
> 
> If you can think of a less ambiguous word for it, let me know.

The name makes sense, we just need to document the host
kernel requirement properly. The error message should of
course mention it as well.

> > Moreover, do you foresee any situation in which users
> > might reasonably want to turn the feature off even though
> > the entire stack (host kernel, QEMU, guest kernel)
> > understands it?
> 
> Nothing clearly compelling.  In the nearish term, being able to turn
> it off to isolate possible bugs could be useful of course.  It's also
> possible that you could have a VM where the latency of each resize
> could be too much downtime - although in that case I doubt you'd want
> to hotplug memory anyway.

It seems like the use case would be fairly narrow, if it
existed at all. Given that, I think we should avoid adding
yet another knob to libvirt until its value can be
unquestionably proven.

-- 
Andrea Bolognani / Red Hat / Virtualization

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

On Wed, Dec 21, 2016 at 09:38:17AM +0100, Andrea Bolognani wrote:
> On Wed, 2016-12-21 at 15:52 +1100, David Gibson wrote:
> > > > I'm not sure if we need a knob.  I think in general enabling for
> > > > pseries-2.9 and later machine types is correct.  The difficulty is
> > > > that for HV guests, we can only enable it if the host kernel also has
> > > > support.  Explicitly setting "resize-hpt=enable" means qemu will not
> > > > start if the kernel doesn't support it.
> > > 
> > > I thought that would be the case for resize-hpt=required,
> > > not resized-hpt=enabled.
> > 
> > resize-hpt=enabled requires the host to support resizing, but not the
> > guest.  resize-hpt=required requires both the host and the guest to
> > support resizing.
> > 
> > If you can think of a less ambiguous word for it, let me know.
> 
> The name makes sense, we just need to document the host
> kernel requirement properly. The error message should of
> course mention it as well.

The error message is currently

"Hash page table resizing not available with this KVM version"

Does that cover it?

> > > Moreover, do you foresee any situation in which users
> > > might reasonably want to turn the feature off even though
> > > the entire stack (host kernel, QEMU, guest kernel)
> > > understands it?
> > 
> > Nothing clearly compelling.  In the nearish term, being able to turn
> > it off to isolate possible bugs could be useful of course.  It's also
> > possible that you could have a VM where the latency of each resize
> > could be too much downtime - although in that case I doubt you'd want
> > to hotplug memory anyway.
> 
> It seems like the use case would be fairly narrow, if it
> existed at all. Given that, I think we should avoid adding
> yet another knob to libvirt until its value can be
> unquestionably proven.

I tend to agree.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [Qemu-ppc] [PATCHv3 for-2.9 0/6] HPT resizing for pseries guests (qemu part)

[Andrea Bolognani]

On Thu, 2016-12-22 at 09:43 +1100, David Gibson wrote:
> > The name makes sense, we just need to document the host
> > kernel requirement properly. The error message should of
> > course mention it as well.
> 
> The error message is currently
> 
> "Hash page table resizing not available with this KVM version"
> 
> Does that cover it?

Sounds good to me.

-- 
Andrea Bolognani / Red Hat / Virtualization