[R4.0] CPU Freq Scaling, or "Why am I stuck at 2.1 Ghz?"

60 views
Skip to first unread message

Eric Duncan

unread,
Dec 6, 2018, 6:54:17 PM12/6/18
to qubes-users
Finally received my new Thinkpad X1 Yoga 3rd gen.

i7-8650U up to 4.2 Ghz Turbo

How can I debug/check that my CPU governor/frequency is scaling correcting under Qubes R4?

So far, the only thing I've found is xentop/xl top that lists the CPU - as a never-changing 2.1 Ghz. Maybe this isn't the best way to measure CPU freq under dom0? All other tools seemed to want to use xfce4 tools, which seemed to only be specific to that fedora VM - and not the xen host.

/TL;DR


I let Windows 10 register itself before wiping the disk and installing Qubes R4. Under Windows, Google Chrome benchmarked around 5300 pts with the online tool I was using. As a test, I also installed Arch Linux briefly to test Chrome performance, and it came in around 4500 pts. I chalk that up to not optimizing anything on the system - just a raw install and no tweaks.

Now, under Qubes R4.0, I'm still noticing a lot of sluggishness/slowdowns just like my older Thinkpad Helix has always had under Qubes R3.2 (and one of the reasons why I waited for this quad core CPU to upgrade my Qubes install). I could never benchmark Chrome under that Helix dual-core low-powered device.

I loaded up Chrome on a new debian-9 VM and... Almost the same extremely sluggish performance. Google Chrome can't even get partially through the benchmarks without timing out, much less finish them.

I've tried assigning 4 and even 8 vcpus to try to max things out.

I am wondering where to start to debug this.

Is it a dom0 cpu scaling thing?

Does Qubes impose some artificial throttling?

Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM is a new concept to me, still trying to figure it out)

I've spent about 3 days on this device with various other issues to get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR 1440p 14" display, etc). I few duckduckgo searches hasn't turned anything up yet; so, i'll continue when I have some time.

Thanks!
-E

Ivan Mitev

unread,
Dec 7, 2018, 1:29:10 AM12/7/18
to qubes...@googlegroups.com


On 12/7/18 1:54 AM, Eric Duncan wrote:
> Finally received my new Thinkpad X1 Yoga 3rd gen.
>
> i7-8650U up to 4.2 Ghz Turbo
>
> How can I debug/check that my CPU governor/frequency is scaling correcting under Qubes R4?
>
> So far, the only thing I've found is xentop/xl top that lists the CPU - as a never-changing 2.1 Ghz. Maybe this isn't the best way to measure CPU freq under dom0? All other tools seemed to want to use xfce4 tools, which seemed to only be specific to that fedora VM - and not the xen host.

see `xenpm`

eg. in dom0:

sudo xenpm get-cpufreq-para


>
> /TL;DR
>
>
> I let Windows 10 register itself before wiping the disk and installing Qubes R4. Under Windows, Google Chrome benchmarked around 5300 pts with the online tool I was using. As a test, I also installed Arch Linux briefly to test Chrome performance, and it came in around 4500 pts. I chalk that up to not optimizing anything on the system - just a raw install and no tweaks.
>
> Now, under Qubes R4.0, I'm still noticing a lot of sluggishness/slowdowns just like my older Thinkpad Helix has always had under Qubes R3.2 (and one of the reasons why I waited for this quad core CPU to upgrade my Qubes install). I could never benchmark Chrome under that Helix dual-core low-powered device.

It could be that the smt=off "fix" for L1TF causes you pain (see issues
4372 and 4252). Unplug your laptop from AC, open a VM, browse the web
casually and check your power consumption - a recent laptop should be
between 5 to 7 W on Qubes with light usage. If you see something >10W
(like I did), try to re-enable smt - which is not really a good thing to
do but that's that or throwing the laptop out of the window. Note: I
haven't tested if recent kernels fixed the issue.


> I loaded up Chrome on a new debian-9 VM and... Almost the same extremely sluggish performance. Google Chrome can't even get partially through the benchmarks without timing out, much less finish them.
>
> I've tried assigning 4 and even 8 vcpus to try to max things out.

You shouldn't configure more vcpus that cpus, that'll add overhead.


> I am wondering where to start to debug this.
>
> Is it a dom0 cpu scaling thing?
>
> Does Qubes impose some artificial throttling?
>
> Is it a lag in iGPU rendering through the DisplayVM? (this DisplayVM is a new concept to me, still trying to figure it out)

DisplayVM ? AFAIK Qubes dev are working to isolate the gui stuff into a
specific domain but I think it was planned for 4.1.

Or maybe you meant dispVM ? If yes, disposable VMs in R4 are a bit
different than R3.2 (way more flexible).


> I've spent about 3 days on this device with various other issues to get to this point (no S3 sleep yet, pixel-perfect scaling of the HDR 1440p 14" display, etc). I few duckduckgo searches hasn't turned anything up yet; so, i'll continue when I have some time.

Good luck :)

Mike Keehan

unread,
Dec 9, 2018, 12:14:00 PM12/9/18
to qubes...@googlegroups.com
Hi Eric,

If your Chrome benchmarks involve 3D acceleration using the GPU, then
they won't work under Qubes.

Each Qube VM renders it's windows in software, which is then copied to
dom0 for display on the Xwindow system. Only dom0 has access to the
GPU, and you are not supposed to run applications on dom0 for security
reasons. (And of course, dom0 has no internet connection anyway.)

Mike.

Stuart Perkins

unread,
Dec 9, 2018, 3:13:05 PM12/9/18
to qubes...@googlegroups.com
Qubes is a "security oriended" OS. If you want to game, use a different physical system. Gaming by its very nature is best done NOT in a VM.

Stuart

John Mitchell

unread,
Dec 10, 2018, 5:22:44 AM12/10/18
to qubes-users
With careful hardware selection you can avoid the pitfalls to gaming in a VM. Well not the security pitfalls, although they are mostly contained in a VM. Also with the correct hardware you can game with 95% of the performance when compared to bare metal. There are many pitfalls to avoid like Nvidia blocking PCI pass-through to AMD reset bugs. These can be avoided with careful hardware selection.

This link will get you started in your search for gaming in a VM.

https://forum.level1techs.com/t/play-games-in-windows-on-linux-pci-passthrough-quick-guide/108981

Please do not bother the good developers here with questions as I believe this is outside the scope of qubes. Take any questions you have to Level1Techs.

John

Reply all
Reply to author
Forward
0 new messages