Date:   Mon, 21 Sep 2020 11:21:54 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Rob Clark <robdclark@...il.com>
Cc:     dri-devel@...ts.freedesktop.org,
        Rob Clark <robdclark@...omium.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-arm-msm@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>, timmurray@...gle.com,
        Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH 0/3] drm: commit_work scheduling

On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> From: Rob Clark <robdclark@...omium.org>
> 
> The android userspace treats the display pipeline as a realtime problem.
> And arguably, if your goal is to not miss frame deadlines (ie. vblank),
> it is.  (See https://lwn.net/Articles/809545/ for the best explaination
> that I found.)
> 
> But this presents a problem with using workqueues for non-blocking
> atomic commit_work(), because the SCHED_FIFO userspace thread(s) can
> preempt the worker.  Which is not really the outcome you want.. once
> the required fences are scheduled, you want to push the atomic commit
> down to hw ASAP.
> 
> But the decision of whether commit_work should be RT or not really
> depends on what userspace is doing.  For a pure CFS userspace display
> pipeline, commit_work() should remain SCHED_NORMAL.
> 
> To handle this, convert non-blocking commit_work() to use per-CRTC
> kthread workers, instead of system_unbound_wq.  Per-CRTC workers are
> used to avoid serializing commits when userspace is using a per-CRTC
> update loop.
> 
> A client-cap is introduced so that userspace can opt-in to SCHED_FIFO
> priority commit work.
> 
> A potential issue is that since 616d91b68cd ("sched: Remove
> sched_setscheduler*() EXPORTs") we have limited RT priority levels,
> meaning that commit_work() ends up running at the same priority level
> as vblank-work.  This shouldn't be a big problem *yet*, due to limited
> use of vblank-work at this point.  And if it could be arranged that
> vblank-work is scheduled before signaling out-fences and/or sending
> pageflip events, it could probably work ok to use a single priority
> level for both commit-work and vblank-work.

The part I don't like about this is that it all feels rather hacked
together, and if we add more stuff (or there's some different thing in the
system that also needs rt scheduling) then it doesn't compose.

So question to rt/worker folks: What's the best way to let userspace set
the scheduling mode and priorities of things the kernel does on its
behalf? Surely we're not the first ones where if userspace runs with some
rt priority it'll starve out the kernel workers that it needs. Hardcoding
something behind a subsystem ioctl (which just means every time userspace
changes what it does, we need a new such flag or mode) can't be the right
thing.

Peter, Tejun?

Thanks, Daniel

> 
> Rob Clark (3):
>   drm/crtc: Introduce per-crtc kworker
>   drm/atomic: Use kthread worker for nonblocking commits
>   drm: Add a client-cap to set scheduling mode
> 
>  drivers/gpu/drm/drm_atomic_helper.c | 13 ++++++----
>  drivers/gpu/drm/drm_auth.c          |  4 ++++
>  drivers/gpu/drm/drm_crtc.c          | 37 +++++++++++++++++++++++++++++
>  drivers/gpu/drm/drm_ioctl.c         | 13 ++++++++++
>  include/drm/drm_atomic.h            | 31 ++++++++++++++++++++++++
>  include/drm/drm_crtc.h              | 10 ++++++++
>  include/uapi/drm/drm.h              | 13 ++++++++++
>  7 files changed, 117 insertions(+), 4 deletions(-)
> 
> -- 
> 2.26.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Powered by blists - more mailing lists