Mouse cursor movement is choppy and unresponsive when CPU is under mild load

[jamke]

How to file a helpful issue

Qubes OS release

R4.1.1.

Brief summary

Mouse cursor movement is choppy and unresponsive when CPU is under mild load (like 1/8 of total CPU power).

I had no such situation on R4.0 even with twice weaker CPU, so I except it to be a regression. Maybe it is connected to the cursor-changing feature of R4.1?

Steps to reproduce

In my case it is 100% reproducible:

1. Install and open qbittorrent in some AppVM connected to internet. This qube has only one 1 CPU out of 8.
2. Add torrent files of Qubes OS or Ubuntu, start to download them and wait when enough internet bandwidth is occupied (~50 Mb/s in my case).
3. Switch to other VM window (not necessary)
4. Move cursor quickly making circles.

Expected behavior

The movement of cursor is not drastically affected by downloads.

Actual behavior

The movement of cursor is very choppy, like 2-4 frames per second at some point. Drastically different from the situation when CPU is idle.

I had no such situation on R4.0 even with twice weaker CPU, so I except it to be a regression, maybe due to cursor changing features or something else.

More information

I made an experiment:

1. Stop all activity in all qubes, so the CPU consumption in xentop whould be almost 0.
2. Start moving mouse rapidly in circles. In this situation I have a CPU consumption according to xentop up to 20%! (20% of Intel i7 (gen11) CPU). How can it be? I compared it with R4.0 and it was 2 times lower on 2 times slower CPU, so, regression is like 4 times, maybe it is the reason of movements being choppy.

Of course I also saw CPU consumption of AppVM I'm moving mouse over it's also high (like 30% of CPU).

Other information

When I start downloads as I mentioned, I see in xentop that CPU consumption is like that: ~30% qube with qbittorrent running ~30% vpn qube ~15% sys-net ~18% sys-firewall So, in total it's about 100% of 1 CPU out of 8 (100% out of 800%). Should be plenty of CPU power left to avoid mouse cursor from being so choppy and unresponsive.

Is it important

For me this situation is critical, mouse cursor is very painful to use. Moving mouse precisely is a problem, selecting text is a pain, and using mouse gestures is hard. So, please help. Maybe there is a way for me to get back to the R4.0-way of cursor functioning?

[DemiMarie]

This is strange. @marmarek any idea what could do this?

[marmarek]

Try xen packages from current-testing repository, recently there were scheduler-related fixes (mostly relevant for system suspend, but still worth a try).

[jamke]

Try xen packages from current-testing repository

How?

$ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing xen

Package xen-2001:4.14.5-12.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

[marmarek]

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --action=update "xen*"

[jamke]

@marmarek I did that and rebooted. And you know, it actually feels much better. Still not perfect, cursor is getting stuck sometimes but still much better, like I had in R4.0. Thank you a lot for such a fast response!

I hope it's not psychosomatic feeling but real change. I'm almost certain because I was able to forget that I have qbittorrent downloading at the background.

[DemiMarie]

Closing as fixed.

[jamke]

Thanks again guys, yes, it's solved for me.

[jamke]

I'm asking to reopen this issue because I have it again. So, it seems the problem appears only once in a while, so I was wrong that it's gone.

I have a lot of CPUs and CPU power not occupied but cursor is moving with ~ 4 FPS, very choppy, hard to use it.

[andrewdavidwong]

@DemiMarie, what's the rationale for adding the ux label to this issue? If it's "because it affects the user experience," then I don't think that's a sufficient criterion. By that logic, almost every issue is a UX issue. I would think that the ux label should apply to issues that involve UX design or decisions in some way, not just every bug that affects users' experience with the system.

[DemiMarie]

@andrewdavidwong good point, removing

[alt3r-3go]

As this looks similar to what had, and the CPU family is close, at least as a test, @jamke - try using cpufreq=none on the Xen command line. For my 12th gen it helped noticeably by switching off Xen's attempts to do power management on it (while its driver doesn't support that gen) and leaving it up to CPU's own autonomous management, which works much better in these circumstances. More details in #4604.

[jamke]

@alt3r-3go how exactly should I add this option? I'm using EFI boot but I have no /boot/efi/EFI/qubes/xen.cfg config. Is kernel parameters in GRUB_CMDLINE_LINUX of /etc/default/grub a place you mean?

[alt3r-3go]

That would be a more permanent option, for testing it's simpler to just use the "edit command line" GRUB functionality - when you see the initial boot screen with boot options, press "e" and you'll get into that mode. You'll see a set of command lines, including the one for Xen and another one for the kernel, you'll want the one for Xen, it can be anywhere, e.g. at the end. After editing the command line, hit Ctrl+X to proceed with the boot.

[jamke]

@alt3r-3go thank you, I will try. But I will add it to grub config because the issue is randomly happening to me. So I will need many reboots to find out if it helps.

Currently I booted and suddenly have this choppy cursor movement without any load from VMs. It's not going away for an hour, so, maybe the reason of the problem is not actually a load but something in xen itself. And load just make similar effect or can start the problem.

[alt3r-3go]

Right, if it's sporadic, then it's more likely to be something else - the power/frequency management stuff is more likely to be visible constantly, though it doesn't hurt to try anyway.

[brendanhoar]

Maybe also be a runtime transition from low-overhead, opcode-based TSC clocksource to high overhead, hypercall-based Xen clocksource?

[jamke]

I tried cpufreq=none, unfortunately mouse movement lags are the same. Even without actual load. No idea what to do.

[jamke]

Maybe also be a runtime transition from low-overhead, opcode-based TSC clocksource to high overhead, hypercall-based Xen clocksource?

How can I check that?

[jamke]

I made another interesting test:

• Shutdown all AppVMs to keep only dom0 running with 0% CPU load (checked in top and xentop).
• The choppy mouse movement is still in place.

So, it's not about load. Maybe I have 2 issues with similar symptoms. What I think, maybe a reason for choppy state without CPU load is a TripleBuffer option that I used in Xorg configs with intel video driver. I removed this option and will monitor the situation further. I don't know how triple-buffer can so drastically affect mouse movement on a %0 CPU load on reasonably modern PC with 64GB of RAM, though.

[maltfield]

+1 This is especially noticeable for me after kicking-off updates on several TemplateVMs. fwiw, I have enabled all updates to go through sys-whonix.

I'm running QubesOS 4.1.2.

[ayakael]

I second @maltfield, the second there's mild load, or something is being written, cursor movement becomes choppy, keyboard starts ratcheting keys when typing, inputs sometimes completly stops for a few moments. This has been occuring for a few months now.

I've since updated to r4.2 and the issues still occur.

Here are my specs: Thinkpad T14 AMD Gen 1 Ryzen Pro 4750U Kernel 6.1.15-1.qubes.fc37 Xen 4.17.2-1.fc37

Being a laptop, keyboard goes through dom0.

[jamke]

@andrewdavidwong affects-4.2

[ayakael]

Of note, it seems like I solved the issue on my side. It was caused by a workaround (using pci=nomsi) to a previous issue endemic to xen support for AMD 4750U, which looks to be solved now.