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.