From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: Peter Zijlstra <peterz@infradead.org>, Tejun Heo <tj@kernel.org>,
timmurray@google.com, linux-arm-msm@vger.kernel.org,
Rob Clark <robdclark@chromium.org>,
linux-kernel@vger.kernel.org (open list)
Subject: [PATCH 0/3] drm: commit_work scheduling
Date: Sat, 19 Sep 2020 12:37:23 -0700 [thread overview]
Message-ID: <20200919193727.2093945-1-robdclark@gmail.com> (raw)
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.
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
next reply other threads:[~2020-09-19 19:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 19:37 Rob Clark [this message]
2020-09-19 19:37 ` [PATCH 1/3] drm/crtc: Introduce per-crtc kworker Rob Clark
2020-09-21 9:20 ` Jani Nikula
2020-09-19 19:37 ` [PATCH 2/3] drm/atomic: Use kthread worker for nonblocking commits Rob Clark
2020-09-21 9:23 ` Daniel Vetter
2020-09-21 14:55 ` Rob Clark
2020-09-22 13:18 ` Daniel Vetter
2020-09-19 19:37 ` [PATCH 3/3] drm: Add a client-cap to set scheduling mode Rob Clark
2020-09-21 9:21 ` [PATCH 0/3] drm: commit_work scheduling Daniel Vetter
2020-09-21 10:49 ` peterz
2020-09-21 14:28 ` Tejun Heo
2020-09-21 15:16 ` Rob Clark
2020-09-21 15:20 ` Rob Clark
2020-09-21 16:19 ` Rob Clark
2020-09-22 6:58 ` Daniel Vetter
2020-09-22 14:48 ` Rob Clark
2020-09-23 15:25 ` Daniel Vetter
2020-09-24 2:33 ` Rob Clark
2020-09-24 8:49 ` Daniel Vetter
2020-09-24 15:24 ` Rob Clark
2020-09-24 16:15 ` Qais Yousef
2020-09-25 8:23 ` Daniel Vetter
2020-09-21 16:10 ` Qais Yousef
2020-09-21 16:23 ` Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200919193727.2093945-1-robdclark@gmail.com \
--to=robdclark@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=robdclark@chromium.org \
--cc=timmurray@google.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox