lkml.org 
[lkml]   [2020]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/3] drm: commit_work scheduling
    On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter <daniel@ffwll.ch> wrote:
    >
    > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
    > > From: Rob Clark <robdclark@chromium.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.

    The ideal thing would be that userspace is in control of the
    priorities.. the setclientcap approach seemed like a reasonable way to
    give the drm-master a way to opt in.

    I suppose instead userspace could use sched_setscheduler().. but that
    would require userspace to be root, and would require some way to find
    the tid.

    Is there some way we could arrange for the per-crtc kthread's to be
    owned by the drm master? That would solve the "must be root" issue.
    And since the target audience is an atomic userspace, I suppose we
    could expose the tid as a read-only property on the crtc?

    BR,
    -R

    > 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@lists.freedesktop.org
    > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
    >
    > --
    > Daniel Vetter
    > Software Engineer, Intel Corporation
    > http://blog.ffwll.ch

    \
     
     \ /
      Last update: 2020-09-21 17:16    [W:4.497 / U:0.260 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site