From: Thomas Zimmermann <[email protected]> Sent: Tuesday, September 30, 2025 
8:04 AM
> 
> 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
> 

Yes, all is good. I was delayed a bit due to some travel, but the test
system has been running for a week now with no warnings or other
issues. From my standpoint, the patch series is good to merge.

Michael

Reply via email to