From: Jonas Ådahl <jad...@redhat.com> In order for compositors to utilize real time scheduling capabilities, it must be ensured by the kernel that calling a drmModeAtomicCommit() with DRM_MODE_ATOMIC_NONBLOCK does not block in a manner that makes the realtime scheduler watchdog send a SIGKILL to the calling process.
Thus, require drmModeAtomicCommit() explicitly with passed DRM_MODE_ATOMIC_NONBLOCK to not block in such a way, i.e. during regular non-mode setting page flips, the kernel must not block any extensive period of time. While blocking for the amount of time needed to trigger SIGKILL (usually 250 ms) already means inadequate behavior due to a large amount of missed frames, thus stuttering, is the result, if drivers still need to behave this way in edge cases, they should behave in away that the calling thread can go to sleep. Signed-off-by: Jonas Ådahl <jad...@redhat.com> --- Hi, This is a follow up from the Display Next Hackfest in Coruña[1], where the topic was discussed, and the conclusion was to try to document the expectations of the kernel when compositors are doing non-blocking page flips. As can be seen, synchronous mode setting commits are not, for the time being, meant to guarantee finishing fast enough, which is fine, but to be able to make use of realtime scheduling, nonblocking updates must behave in a sensible manner. I took it so far to describe how drivers should handle situations when checking an update can potentially take a very very long time, but if that should just never be allowed to happen, it can be reworded. The main take away should be that it's a kernel bug if a non-blocking commit blocks for more than a few milliseconds. Jonas [1] https://events.pages.igalia.com/linuxdisplaynexthackfest/ include/uapi/drm/drm_mode.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index c082810c08a8..1953ae1a37d2 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -1112,6 +1112,12 @@ struct drm_mode_destroy_dumb { * IOCTL returns immediately instead of waiting for the changes to be applied * in hardware. Note, the driver will still check that the update can be * applied before retuning. + * + * The driver must not leave the calling thread in a running state for any + * extensive period of time to avoid the process receiving SIGKILL by the + * realtime scheduler. This means if checking the update needs to wait for an + * excessive amount of time, the running state of the calling thread must be + * changed accordingly while waiting. */ #define DRM_MODE_ATOMIC_NONBLOCK 0x0200 /** -- 2.44.0.501.g19981daefd.dirty
