All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org, Tejun Heo <tj@kernel.org>,
	timmurray@google.com, Daniel Vetter <daniel@ffwll.ch>,
	Qais Yousef <qais.yousef@arm.com>,
	Rob Clark <robdclark@chromium.org>,
	linux-kernel@vger.kernel.org (open list)
Subject: [PATCH v2 0/3] drm: commit_work scheduling
Date: Wed, 30 Sep 2020 14:17:19 -0700	[thread overview]
Message-ID: <20200930211723.3028059-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.  And the last patch exposes the task id to userspace as
a CRTC property, so that userspace can adjust the priority and sched
policy to fit it's needs.


v2: Drop client cap and in-kernel setting of priority/policy in
    favor of exposing the kworker tid to userspace so that user-
    space can set priority/policy.

Rob Clark (3):
  drm/crtc: Introduce per-crtc kworker
  drm/atomic: Use kthread worker for nonblocking commits
  drm: Expose CRTC's kworker task id

 drivers/gpu/drm/drm_atomic_helper.c | 13 ++++++++----
 drivers/gpu/drm/drm_crtc.c          | 14 +++++++++++++
 drivers/gpu/drm/drm_mode_config.c   | 14 +++++++++++++
 drivers/gpu/drm/drm_mode_object.c   |  4 ++++
 include/drm/drm_atomic.h            | 31 +++++++++++++++++++++++++++++
 include/drm/drm_crtc.h              |  8 ++++++++
 include/drm/drm_mode_config.h       |  9 +++++++++
 include/drm/drm_property.h          |  9 +++++++++
 8 files changed, 98 insertions(+), 4 deletions(-)

-- 
2.26.2


WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: Rob Clark <robdclark@chromium.org>,
	linux-arm-msm@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>,
	timmurray@google.com, Tejun Heo <tj@kernel.org>,
	Qais Yousef <qais.yousef@arm.com>
Subject: [PATCH v2 0/3] drm: commit_work scheduling
Date: Wed, 30 Sep 2020 14:17:19 -0700	[thread overview]
Message-ID: <20200930211723.3028059-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.  And the last patch exposes the task id to userspace as
a CRTC property, so that userspace can adjust the priority and sched
policy to fit it's needs.


v2: Drop client cap and in-kernel setting of priority/policy in
    favor of exposing the kworker tid to userspace so that user-
    space can set priority/policy.

Rob Clark (3):
  drm/crtc: Introduce per-crtc kworker
  drm/atomic: Use kthread worker for nonblocking commits
  drm: Expose CRTC's kworker task id

 drivers/gpu/drm/drm_atomic_helper.c | 13 ++++++++----
 drivers/gpu/drm/drm_crtc.c          | 14 +++++++++++++
 drivers/gpu/drm/drm_mode_config.c   | 14 +++++++++++++
 drivers/gpu/drm/drm_mode_object.c   |  4 ++++
 include/drm/drm_atomic.h            | 31 +++++++++++++++++++++++++++++
 include/drm/drm_crtc.h              |  8 ++++++++
 include/drm/drm_mode_config.h       |  9 +++++++++
 include/drm/drm_property.h          |  9 +++++++++
 8 files changed, 98 insertions(+), 4 deletions(-)

-- 
2.26.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

             reply	other threads:[~2020-09-30 21:16 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 21:17 Rob Clark [this message]
2020-09-30 21:17 ` [PATCH v2 0/3] drm: commit_work scheduling Rob Clark
2020-09-30 21:17 ` [PATCH v2 1/3] drm/crtc: Introduce per-crtc kworker Rob Clark
2020-09-30 21:17   ` Rob Clark
2020-09-30 21:17 ` [PATCH v2 2/3] drm/atomic: Use kthread worker for nonblocking commits Rob Clark
2020-09-30 21:17   ` Rob Clark
2020-09-30 21:17 ` [PATCH v2 3/3] drm: Expose CRTC's kworker task id Rob Clark
2020-09-30 21:17   ` Rob Clark
2020-10-01  7:25 ` [PATCH v2 0/3] drm: commit_work scheduling Daniel Vetter
2020-10-01  7:25   ` Daniel Vetter
2020-10-01 15:15   ` Rob Clark
2020-10-01 15:15     ` Rob Clark
2020-10-01 15:25     ` Daniel Vetter
2020-10-01 15:25       ` Daniel Vetter
2020-10-02 10:52       ` Ville Syrjälä
2020-10-02 10:52         ` Ville Syrjälä
2020-10-02 11:05         ` Ville Syrjälä
2020-10-02 11:05           ` Ville Syrjälä
2020-10-02 17:55           ` Rob Clark
2020-10-02 17:55             ` Rob Clark
2020-10-05 12:15             ` Ville Syrjälä
2020-10-05 12:15               ` Ville Syrjälä
2020-10-05 14:15               ` Daniel Vetter
2020-10-05 14:15                 ` Daniel Vetter
2020-10-05 22:58                 ` Rob Clark
2020-10-05 22:58                   ` Rob Clark
2020-10-07 16:44               ` Rob Clark
2020-10-07 16:44                 ` Rob Clark
2020-10-08  8:24                 ` Ville Syrjälä
2020-10-08  8:24                   ` Ville Syrjälä
2020-10-16 16:27                   ` Rob Clark
2020-10-16 16:27                     ` Rob Clark
2020-10-02 11:01 ` Qais Yousef
2020-10-02 11:01   ` Qais Yousef
2020-10-02 18:07   ` Rob Clark
2020-10-02 18:07     ` Rob Clark
2020-10-05 15:00     ` Qais Yousef
2020-10-05 15:00       ` Qais Yousef
2020-10-05 23:24       ` Rob Clark
2020-10-05 23:24         ` Rob Clark
2020-10-06  9:08         ` Daniel Vetter
2020-10-06  9:08           ` Daniel Vetter
2020-10-06 10:01           ` Peter Zijlstra
2020-10-06 10:01             ` Peter Zijlstra
2020-10-06 10:59         ` Qais Yousef
2020-10-06 10:59           ` Qais Yousef
2020-10-06 20:04           ` Rob Clark
2020-10-06 20:04             ` Rob Clark
2020-10-07 10:36             ` Qais Yousef
2020-10-07 10:36               ` Qais Yousef
2020-10-07 15:57               ` Rob Clark
2020-10-07 15:57                 ` Rob Clark
2020-10-07 16:30                 ` Qais Yousef
2020-10-07 16:30                   ` Qais Yousef
2020-10-08  9:10                   ` Daniel Vetter
2020-10-08  9:10                     ` Daniel Vetter

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=20200930211723.3028059-1-robdclark@gmail.com \
    --to=robdclark@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qais.yousef@arm.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.