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.
