Hi
Am 16.09.25 um 17:00 schrieb Michael Kelley:
From: Thomas Zimmermann <[email protected]> Sent: Tuesday, September 16, 2025
1:31 AM
Hi
Am 09.09.25 um 05:29 schrieb Michael Kelley:
From: Michael Kelley Sent: Thursday, September 4, 2025 10:36 PM
From: Thomas Zimmermann <[email protected]> Sent: Thursday, September 4, 2025
7:56 AM
Compositors often depend on vblanks to limit their display-update
rate. Without, they see vblank events ASAP, which breaks the rate-
limit feature. This creates high CPU overhead. It is especially a
problem with virtual devices with fast framebuffer access.
The series moves vkms' vblank timer to DRM and converts the hyperv
DRM driver. An earlier version of this series contains examples of
other updated drivers. In principle, any DRM driver without vblank
hardware can use the timer.
I've tested this patch set in a Hyper-V guest against the linux-next20250829
kernel. All looks good. Results and perf are the same as reported here [4].
So far I haven't seen the "vblank timer overrun" error, which is consistent
with the changes you made since my earlier testing. I'll keep running this
test kernel for a while to see if anything anomalous occurs.
As I continued to run with this patch set, I got a single occurrence of this
WARN_ON. I can't associate it with any particular action as I didn't notice
it until well after it occurred.
I've investigated. The stack trace comes from the kernel console's
display update. It runs concurrently to the vblank timeout. What likely
happens here is that the update code reads two values and in between,
the vblank timeout updates them. So the update then compares an old and
a new value; leading to an incorrect result with triggers the warning.
I'll include a fix in the series' next iteration. But I also think that
it's not critical. DRM's vblank helpers can usually deal with such problems.
Thanks! I'm giving your v4 series a try now. Good that the underlying
problem is not critical. But I was seeing the WARN_ON() output in
dmesg every few days (a total of 4 times now), and that's not really
acceptable even if everything continues to work correctly.
So it's probably a good sign that I haven't heard from you recently. :)
If you haven't seen any warnings with v4, I'd like to merge the series soon.
Best regards
Thomas
Michael
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
