[Qemu-devel] Speed menu for GTK interfaace

[Qemu-devel] Speed menu for GTK interfaace

[Programmingkid]

Hello, I was wondering if you would accept a patch that added a Speed menu to the GTK interface. This would allow the user to change how much CPU time the emulated CPU would see. 

Re: [Qemu-devel] Speed menu for GTK interfaace

[Gerd Hoffmann]

On So, 2017-01-01 at 13:15 -0500, Programmingkid wrote:
> Hello, I was wondering if you would accept a patch that added a Speed
> menu to the GTK interface. This would allow the user to change how
> much CPU time the emulated CPU would see. 

/me wonders what exactly would the menu entries do?

cheers,
  Gerd

Re: [Qemu-devel] Speed menu for GTK interfaace

[Programmingkid]

On Jan 3, 2017, at 3:59 AM, Gerd Hoffmann wrote:

> On So, 2017-01-01 at 13:15 -0500, Programmingkid wrote:
>> Hello, I was wondering if you would accept a patch that added a Speed
>> menu to the GTK interface. This would allow the user to change how
>> much CPU time the emulated CPU would see. 
> 
> /me wonders what exactly would the menu entries do?
> 
> cheers,
>  Gerd

It is quite simple, there would be a 100% to a 1% menu item. It would look like
this:

Speed
-------
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
1%


Each menu item would call cpu_throttle_set(). The value sent to this function would
be determined like this:
speed = -1 * menu_number + 100;

speed would be sent to the cpu_throttle_set() function. This function would reduce
the CPU usage of QEMU on the host. 

Why would someone want to slow down QEMU?
- The user is using a laptop and don't want it to heat up.
- The user wants to slow down a video game that is a little too challenging.
- The user wants to save energy.
- The user wants to conduct some kind of stress test on a program and see how
it handles under low cpu resources. 

Hope this helps. Thank you for responding.

Re: [Qemu-devel] Speed menu for GTK interfaace

[Gerd Hoffmann]

  Hi,

> It is quite simple, there would be a 100% to a 1% menu item. It would look like
> this:
> 
> Speed
> -------
> 100%
> 90%
> 80%
> 70%
> 60%
> 50%
> 40%
> 30%
> 20%
> 10%
> 1%
> 
> 
> Each menu item would call cpu_throttle_set(). The value sent to this function would
> be determined like this:
> speed = -1 * menu_number + 100;

ok, that is the info I was looking for.

> speed would be sent to the cpu_throttle_set() function. This function would reduce
> the CPU usage of QEMU on the host. 
> 
> Why would someone want to slow down QEMU?
> - The user is using a laptop and don't want it to heat up.

Sort-of makes sense, to keep the laptop quiet.

> - The user wants to slow down a video game that is a little too challenging.

Sure this would work?  Throttling isn't a smooth slowdown, the cpu
continues to run at full speed and is forced to pause now and then.

> - The user wants to save energy.

Pointless.  Laptop may run longer, but your job needs more time to
complete too.  And constant vcpu start/stop isn't good to save power,
the cpus can't enter deep sleep states then because of the frequent
wakeups.

> - The user wants to conduct some kind of stress test on a program and see how
> it handles under low cpu resources. 

Makes sense too.

We already have "pause" in gtk, adding a "throttle" item next to it
looks reasonable to me.  I don't think it is that useful to have 10%
steps in there, you probably never throttle 10% in practice.  It's
probably more useful to have something like "throttle -> off / 50% /
90% / 95% / 99%".

cheers,
  Gerd

Re: [Qemu-devel] Speed menu for GTK interfaace

[Programmingkid]

On Jan 4, 2017, at 3:37 AM, Gerd Hoffmann wrote:

>  Hi,
> 
>> It is quite simple, there would be a 100% to a 1% menu item. It would look like
>> this:
>> 
>> Speed
>> -------
>> 100%
>> 90%
>> 80%
>> 70%
>> 60%
>> 50%
>> 40%
>> 30%
>> 20%
>> 10%
>> 1%
>> 
>> 
>> Each menu item would call cpu_throttle_set(). The value sent to this function would
>> be determined like this:
>> speed = -1 * menu_number + 100;
> 
> ok, that is the info I was looking for.
> 
>> speed would be sent to the cpu_throttle_set() function. This function would reduce
>> the CPU usage of QEMU on the host. 
>> 
>> Why would someone want to slow down QEMU?
>> - The user is using a laptop and don't want it to heat up.
> 
> Sort-of makes sense, to keep the laptop quiet.
> 
>> - The user wants to slow down a video game that is a little too challenging.
> 
> Sure this would work?  Throttling isn't a smooth slowdown, the cpu
> continues to run at full speed and is forced to pause now and then.
> 
>> - The user wants to save energy.
> 
> Pointless.  Laptop may run longer, but your job needs more time to
> complete too.  And constant vcpu start/stop isn't good to save power,
> the cpus can't enter deep sleep states then because of the frequent
> wakeups.
> 
>> - The user wants to conduct some kind of stress test on a program and see how
>> it handles under low cpu resources. 
> 
> Makes sense too.
> 
> We already have "pause" in gtk, adding a "throttle" item next to it
> looks reasonable to me.  I don't think it is that useful to have 10%
> steps in there, you probably never throttle 10% in practice.  It's
> probably more useful to have something like "throttle -> off / 50% /
> 90% / 95% / 99%".

Actually the 10% one is the one I use the most. I use it when I have to
test code in OpenBIOS. I wouldn't mind adding a 95% menu item.

Re: [Qemu-devel] Speed menu for GTK interfaace

[Daniel P. Berrange]

On Wed, Jan 04, 2017 at 09:37:39AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > It is quite simple, there would be a 100% to a 1% menu item. It would look like
> > this:
> > 
> > Speed
> > -------
> > 100%
> > 90%
> > 80%
> > 70%
> > 60%
> > 50%
> > 40%
> > 30%
> > 20%
> > 10%
> > 1%
> > 
> > 
> > Each menu item would call cpu_throttle_set(). The value sent to this function would
> > be determined like this:
> > speed = -1 * menu_number + 100;
> 
> ok, that is the info I was looking for.
> 
> > speed would be sent to the cpu_throttle_set() function. This function would reduce
> > the CPU usage of QEMU on the host. 
> > 
> > Why would someone want to slow down QEMU?
> > - The user is using a laptop and don't want it to heat up.
> 
> Sort-of makes sense, to keep the laptop quiet.
> 
> > - The user wants to slow down a video game that is a little too challenging.
> 
> Sure this would work?  Throttling isn't a smooth slowdown, the cpu
> continues to run at full speed and is forced to pause now and then.
> 
> > - The user wants to save energy.
> 
> Pointless.  Laptop may run longer, but your job needs more time to
> complete too.  And constant vcpu start/stop isn't good to save power,
> the cpus can't enter deep sleep states then because of the frequent
> wakeups.
> 
> > - The user wants to conduct some kind of stress test on a program and see how
> > it handles under low cpu resources. 
> 
> Makes sense too.
> 
> We already have "pause" in gtk, adding a "throttle" item next to it
> looks reasonable to me.  I don't think it is that useful to have 10%
> steps in there, you probably never throttle 10% in practice.  It's
> probably more useful to have something like "throttle -> off / 50% /
> 90% / 95% / 99%".

This feels like going down the slippery slope to turn the GTK frontend
into a full mgmt UI, which is something we've said we don't want todo
inside QEMU UI frontends. IMHO this kind of feature is best left to
external mgmt layers, like  virt-manager/GNOME Boxes/etc. It is already
possible to timebox VMs CPU execution using cgroups quotas via libvirt.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] Speed menu for GTK interfaace

[Programmingkid]

On Jan 4, 2017, at 10:51 AM, Daniel P. Berrange wrote:

> On Wed, Jan 04, 2017 at 09:37:39AM +0100, Gerd Hoffmann wrote:
>>  Hi,
>> 
>>> It is quite simple, there would be a 100% to a 1% menu item. It would look like
>>> this:
>>> 
>>> Speed
>>> -------
>>> 100%
>>> 90%
>>> 80%
>>> 70%
>>> 60%
>>> 50%
>>> 40%
>>> 30%
>>> 20%
>>> 10%
>>> 1%
>>> 
>>> 
>>> Each menu item would call cpu_throttle_set(). The value sent to this function would
>>> be determined like this:
>>> speed = -1 * menu_number + 100;
>> 
>> ok, that is the info I was looking for.
>> 
>>> speed would be sent to the cpu_throttle_set() function. This function would reduce
>>> the CPU usage of QEMU on the host. 
>>> 
>>> Why would someone want to slow down QEMU?
>>> - The user is using a laptop and don't want it to heat up.
>> 
>> Sort-of makes sense, to keep the laptop quiet.
>> 
>>> - The user wants to slow down a video game that is a little too challenging.
>> 
>> Sure this would work?  Throttling isn't a smooth slowdown, the cpu
>> continues to run at full speed and is forced to pause now and then.
>> 
>>> - The user wants to save energy.
>> 
>> Pointless.  Laptop may run longer, but your job needs more time to
>> complete too.  And constant vcpu start/stop isn't good to save power,
>> the cpus can't enter deep sleep states then because of the frequent
>> wakeups.
>> 
>>> - The user wants to conduct some kind of stress test on a program and see how
>>> it handles under low cpu resources. 
>> 
>> Makes sense too.
>> 
>> We already have "pause" in gtk, adding a "throttle" item next to it
>> looks reasonable to me.  I don't think it is that useful to have 10%
>> steps in there, you probably never throttle 10% in practice.  It's
>> probably more useful to have something like "throttle -> off / 50% /
>> 90% / 95% / 99%".
> 
> This feels like going down the slippery slope to turn the GTK frontend
> into a full mgmt UI, which is something we've said we don't want todo
> inside QEMU UI frontends. IMHO this kind of feature is best left to
> external mgmt layers, like  virt-manager/GNOME Boxes/etc. It is already
> possible to timebox VMs CPU execution using cgroups quotas via libvirt.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Are you saying that so we can use your Virt-manager? The thing is having more
options is a good thing. If one solution doesn't work, another solution might.
We don't live in a world with only one Linux distribution. We live in a world
with many Linux distributions. We have the power of choice. There currently
isn't a single QEMU front-end that runs on all three operating systems. Yes the
Linux people do have Virt-manager, but what about the Windows and Macintosh
people. They are not so fortunate. Enhancing the GTK front-end does not
hurt any of the Virt-manager users at all. This change is just for the people
who prefer the GTK front-end.

Re: [Qemu-devel] Speed menu for GTK interfaace

[Daniel P. Berrange]

On Wed, Jan 04, 2017 at 11:01:30AM -0500, Programmingkid wrote:
> 
> On Jan 4, 2017, at 10:51 AM, Daniel P. Berrange wrote:
> 
> > On Wed, Jan 04, 2017 at 09:37:39AM +0100, Gerd Hoffmann wrote:
> >>  Hi,
> >> 
> >>> It is quite simple, there would be a 100% to a 1% menu item. It would look like
> >>> this:
> >>> 
> >>> Speed
> >>> -------
> >>> 100%
> >>> 90%
> >>> 80%
> >>> 70%
> >>> 60%
> >>> 50%
> >>> 40%
> >>> 30%
> >>> 20%
> >>> 10%
> >>> 1%
> >>> 
> >>> 
> >>> Each menu item would call cpu_throttle_set(). The value sent to this function would
> >>> be determined like this:
> >>> speed = -1 * menu_number + 100;
> >> 
> >> ok, that is the info I was looking for.
> >> 
> >>> speed would be sent to the cpu_throttle_set() function. This function would reduce
> >>> the CPU usage of QEMU on the host. 
> >>> 
> >>> Why would someone want to slow down QEMU?
> >>> - The user is using a laptop and don't want it to heat up.
> >> 
> >> Sort-of makes sense, to keep the laptop quiet.
> >> 
> >>> - The user wants to slow down a video game that is a little too challenging.
> >> 
> >> Sure this would work?  Throttling isn't a smooth slowdown, the cpu
> >> continues to run at full speed and is forced to pause now and then.
> >> 
> >>> - The user wants to save energy.
> >> 
> >> Pointless.  Laptop may run longer, but your job needs more time to
> >> complete too.  And constant vcpu start/stop isn't good to save power,
> >> the cpus can't enter deep sleep states then because of the frequent
> >> wakeups.
> >> 
> >>> - The user wants to conduct some kind of stress test on a program and see how
> >>> it handles under low cpu resources. 
> >> 
> >> Makes sense too.
> >> 
> >> We already have "pause" in gtk, adding a "throttle" item next to it
> >> looks reasonable to me.  I don't think it is that useful to have 10%
> >> steps in there, you probably never throttle 10% in practice.  It's
> >> probably more useful to have something like "throttle -> off / 50% /
> >> 90% / 95% / 99%".
> > 
> > This feels like going down the slippery slope to turn the GTK frontend
> > into a full mgmt UI, which is something we've said we don't want todo
> > inside QEMU UI frontends. IMHO this kind of feature is best left to
> > external mgmt layers, like  virt-manager/GNOME Boxes/etc. It is already
> > possible to timebox VMs CPU execution using cgroups quotas via libvirt.
> 
> Are you saying that so we can use your Virt-manager? The thing is having more
> options is a good thing. If one solution doesn't work, another solution might.
> We don't live in a world with only one Linux distribution. We live in a world
> with many Linux distributions. We have the power of choice. There currently
> isn't a single QEMU front-end that runs on all three operating systems. Yes the
> Linux people do have Virt-manager, but what about the Windows and Macintosh
> people. They are not so fortunate. Enhancing the GTK front-end does not
> hurt any of the Virt-manager users at all. This change is just for the people
> who prefer the GTK front-end.

This is not about choice, it is about the focusing QEMU community resources
where they are most effectively applied. Turning the GTK front-end into a
fully featured mgmt UI would put a significant, ongoing burden on the QEMU
maintainers over the long term. This will taking resources away from other
areas of work in QEMU, just to duplicate features that already exist / will
exist in layers above / apps external to QEMU.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

Re: [Qemu-devel] Speed menu for GTK interfaace

[Programmingkid]

On Jan 4, 2017, at 11:19 AM, Daniel P. Berrange wrote:

> On Wed, Jan 04, 2017 at 11:01:30AM -0500, Programmingkid wrote:
>> 
>> On Jan 4, 2017, at 10:51 AM, Daniel P. Berrange wrote:
>> 
>>> On Wed, Jan 04, 2017 at 09:37:39AM +0100, Gerd Hoffmann wrote:
>>>> Hi,
>>>> 
>>>>> It is quite simple, there would be a 100% to a 1% menu item. It would look like
>>>>> this:
>>>>> 
>>>>> Speed
>>>>> -------
>>>>> 100%
>>>>> 90%
>>>>> 80%
>>>>> 70%
>>>>> 60%
>>>>> 50%
>>>>> 40%
>>>>> 30%
>>>>> 20%
>>>>> 10%
>>>>> 1%
>>>>> 
>>>>> 
>>>>> Each menu item would call cpu_throttle_set(). The value sent to this function would
>>>>> be determined like this:
>>>>> speed = -1 * menu_number + 100;
>>>> 
>>>> ok, that is the info I was looking for.
>>>> 
>>>>> speed would be sent to the cpu_throttle_set() function. This function would reduce
>>>>> the CPU usage of QEMU on the host. 
>>>>> 
>>>>> Why would someone want to slow down QEMU?
>>>>> - The user is using a laptop and don't want it to heat up.
>>>> 
>>>> Sort-of makes sense, to keep the laptop quiet.
>>>> 
>>>>> - The user wants to slow down a video game that is a little too challenging.
>>>> 
>>>> Sure this would work?  Throttling isn't a smooth slowdown, the cpu
>>>> continues to run at full speed and is forced to pause now and then.
>>>> 
>>>>> - The user wants to save energy.
>>>> 
>>>> Pointless.  Laptop may run longer, but your job needs more time to
>>>> complete too.  And constant vcpu start/stop isn't good to save power,
>>>> the cpus can't enter deep sleep states then because of the frequent
>>>> wakeups.
>>>> 
>>>>> - The user wants to conduct some kind of stress test on a program and see how
>>>>> it handles under low cpu resources. 
>>>> 
>>>> Makes sense too.
>>>> 
>>>> We already have "pause" in gtk, adding a "throttle" item next to it
>>>> looks reasonable to me.  I don't think it is that useful to have 10%
>>>> steps in there, you probably never throttle 10% in practice.  It's
>>>> probably more useful to have something like "throttle -> off / 50% /
>>>> 90% / 95% / 99%".
>>> 
>>> This feels like going down the slippery slope to turn the GTK frontend
>>> into a full mgmt UI, which is something we've said we don't want todo
>>> inside QEMU UI frontends. IMHO this kind of feature is best left to
>>> external mgmt layers, like  virt-manager/GNOME Boxes/etc. It is already
>>> possible to timebox VMs CPU execution using cgroups quotas via libvirt.
>> 
>> Are you saying that so we can use your Virt-manager? The thing is having more
>> options is a good thing. If one solution doesn't work, another solution might.
>> We don't live in a world with only one Linux distribution. We live in a world
>> with many Linux distributions. We have the power of choice. There currently
>> isn't a single QEMU front-end that runs on all three operating systems. Yes the
>> Linux people do have Virt-manager, but what about the Windows and Macintosh
>> people. They are not so fortunate. Enhancing the GTK front-end does not
>> hurt any of the Virt-manager users at all. This change is just for the people
>> who prefer the GTK front-end.
> 
> This is not about choice, it is about the focusing QEMU community resources
> where they are most effectively applied. Turning the GTK front-end into a
> fully featured mgmt UI would put a significant, ongoing burden on the QEMU
> maintainers over the long term. This will taking resources away from other
> areas of work in QEMU, just to duplicate features that already exist / will
> exist in layers above / apps external to QEMU.

I think we can afford some resource being spent on the GTK interface.

Re: [Qemu-devel] Speed menu for GTK interfaace

[Gerd Hoffmann]

  Hi,

> > We already have "pause" in gtk, adding a "throttle" item next to it
> > looks reasonable to me.  I don't think it is that useful to have 10%
> > steps in there, you probably never throttle 10% in practice.  It's
> > probably more useful to have something like "throttle -> off / 50% /
> > 90% / 95% / 99%".
> 
> This feels like going down the slippery slope to turn the GTK frontend
> into a full mgmt UI, which is something we've said we don't want todo
> inside QEMU UI frontends. IMHO this kind of feature is best left to
> external mgmt layers, like  virt-manager/GNOME Boxes/etc. It is already
> possible to timebox VMs CPU execution using cgroups quotas via libvirt.

Well, except that libvirt doesn't support gtk.  And gtk is what you get
by default when using qemu ad-hoc, without libvirt.  Adding features to
gtk which make sense in that context still looks useful to me.

Alternatively we could add qmp+hmp commands for cpu throttling, that way
libvirt can support the feature and with gtk it can be used too, via
monitor tab, even in case we don't create new menu items for it.

cheers,
  Gerd