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.