Re: [PATCH v3 3/4] fbdev/deferred-io: Support contiguous kernel memory framebuffers

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 05.06.25 um 19:38 schrieb Michael Kelley:
[...]
>> I try to address the problem with the patches at
>>
>> https://lore.kernel.org/dri-devel/20250605152637.98493-1-tzimmermann@suse.de/
>>
>> Testing and feedback is much appreciated.
>>
> Nice!
>
> I ran the same test case with your patches, and everything works well. The
> hyperv_drm numbers are now pretty much the same as the hyperv_fb
> numbers for both elapsed time and system CPU time -- within a few percent.
> For hyperv_drm, there's no longer a gap in the elapsed time and system
> CPU time. No errors due to the guest-to-host ring buffer being full. Total
> messages to Hyper-V for hyperv_drm are now a few hundred instead of 3M.

Sounds great. Credit also goes to the vkms devs, which already have the 
software vblank in their driver.

This might need better support for cases where display updates take 
exceptionally long, but I can see this being merged as a DRM feature.

> The hyperv_drm message count is still a little higher than for hyperv_fb,
> presumably because the simulated vblank rate in hyperv_drm is higher than
> the 20 Hz rate used by hyperv_fb deferred I/O. But the overall numbers are
> small enough that the difference is in the noise. Question: what is the default
> value for the simulated vblank rate? Just curious ...

As with a hardware interrupt, the vblank rate comes from the programmed 
display mode, so most likely 60 Hz. The difference in the update 
frequency could explain the remaining differences to hyperv_fb.

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)