Call for feedback on dynamic Xen CPU Hotplugging under Qubes

Hello everyone.

As you may know, I am on a quest to squeeze every last drop of performance out of QubesOS, both for interactive tasks and for gaming.

One of my ideas has been Qubes Window Boost: Dynamic, window focus-based CPU pinning, which works very well, but I have thought to take it even further. First, though, I’d first like to ask for feedback.

I am considering writing a secondary Window Boost script, though this time it would utilize Xen’s CPU hot plugging to even more agressively take resources away from idle Qubes. The rationale is simple: more cores assigned to a background Qube = more time spent context switching, as Linux balances tasks across all available cores. As such, it’s not really feasible to e.g. have all your Qubes have 20 vCPUs assigned at all times, as this will visibly degrade performance.

Enter dynamic hotplugging: What if I used a mechanism similar to Window Boost (e.g. window focus events*) to dynamically take vCPUs away from Qubes when they are not focused? This would allow the user to, for example, have several interactive Qubes (browser, instant messaging, libreoffice) running at the same time with e.g. 8+ vCPUs assigned, but not have to worry about performance degradation. When a qube’s window is focused, it is allowed to utilize all 8 vCPUs, but when it’s unfocused, Xen would take all but 1 (configurable) vCPUs away.

I know that this is technically possible (xl vcpu-set + udev) and I have a very shoddy PoC (not automatic) ready, but I’d like to hear some feedback from everyone. Especially on the following three fronts:

  1. Do you think it’s overkill?
  2. Do you see any unexpected failure modes of such an approach?
  3. How do you think this should be implemented (window focus events, shortcuts, something else)?

Thanks in advance for all your answers.

* Window Boost is not such an extreme measure, while this would be. As such it may be a better idea to have it be semi-automatic with e.g. a keyboard shortcut and not necessarily window focus change events.

3 Likes

Hello

This is a cool idea. I’d be interested to see performance benchmarks of this.

How does this compare? An idea to measure would be for a 12 cores system, to have 6 qubes limited to 1 core and the benchmarked qube running 12 cores, and all the qubes running with 12 cores then benchmark again?

The workload in the “other qubes” should remain identical across runs. You could go further if you have an Intel CPU with an heterogeneous core topology and see how it helps against pinning the focused qube to performance only.

I’m afraid that it might not be interesting if the performance improvement is not significant.

1 Like