From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Rob Clark <robdclark@gmail.com>,
Rob Clark <robdclark@chromium.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Tim Murray <timmurray@google.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Tejun Heo <tj@kernel.org>, Qais Yousef <qais.yousef@arm.com>
Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling
Date: Fri, 2 Oct 2020 14:05:44 +0300 [thread overview]
Message-ID: <20201002110544.GB6112@intel.com> (raw)
In-Reply-To: <20201002105256.GA6112@intel.com>
On Fri, Oct 02, 2020 at 01:52:56PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 01, 2020 at 05:25:55PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 1, 2020 at 5:15 PM Rob Clark <robdclark@gmail.com> wrote:
> > >
> > > On Thu, Oct 1, 2020 at 12:25 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at 11:16 PM Rob Clark <robdclark@gmail.com> 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. 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.
> > > >
> > > > Yeah I think this looks more reasonable. Still a bit irky interface,
> > > > so I'd like to get some kworker/rt ack on this. Other opens:
> > > > - needs userspace, the usual drill
> > >
> > > fwiw, right now the userspace is "modetest + chrt".. *probably* the
> > > userspace will become a standalone helper or daemon, mostly because
> > > the chrome gpu-process sandbox does not allow setting SCHED_FIFO. I'm
> > > still entertaining the possibility of switching between rt and cfs
> > > depending on what is in the foreground (ie. only do rt for android
> > > apps).
> > >
> > > > - we need this also for vblank workers, otherwise this wont work for
> > > > drivers needing those because of another priority inversion.
> > >
> > > I have a thought on that, see below..
> >
> > Hm, not seeing anything about vblank worker below?
> >
> > > > - we probably want some indication of whether this actually does
> > > > something useful, not all drivers use atomic commit helpers. Not sure
> > > > how to do that.
> > >
> > > I'm leaning towards converting the other drivers over to use the
> > > per-crtc kwork, and then dropping the 'commit_work` from atomic state.
> > > I can add a patch to that, but figured I could postpone that churn
> > > until there is some by-in on this whole idea.
> >
> > i915 has its own commit code, it's not even using the current commit
> > helpers (nor the commit_work). Not sure how much other fun there is.
>
> I don't think we want per-crtc threads for this in i915. Seems
> to me easier to guarantee atomicity across multiple crtcs if
> we just commit them from the same thread.
Oh, and we may have to commit things in a very specific order
to guarantee the hw doesn't fall over, so yeah definitely per-crtc
thread is a no go.
I don't even understand the serialization argument. If the commits
are truly independent then why isn't the unbound wq enough to avoid
the serialization? It should just spin up a new thread for each commit
no?
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2020-10-02 11:05 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` [PATCH v2 2/3] drm/atomic: Use kthread worker for nonblocking commits Rob Clark
2020-09-30 21:17 ` [PATCH v2 3/3] drm: Expose CRTC's kworker task id Rob Clark
2020-10-01 7:25 ` [PATCH v2 0/3] drm: commit_work scheduling Daniel Vetter
2020-10-01 15:15 ` Rob Clark
2020-10-01 15:25 ` Daniel Vetter
2020-10-02 10:52 ` Ville Syrjälä
2020-10-02 11:05 ` Ville Syrjälä [this message]
2020-10-02 17:55 ` Rob Clark
2020-10-05 12:15 ` Ville Syrjälä
2020-10-05 14:15 ` Daniel Vetter
2020-10-05 22:58 ` Rob Clark
2020-10-07 16:44 ` Rob Clark
2020-10-08 8:24 ` Ville Syrjälä
2020-10-16 16:27 ` Rob Clark
2020-10-02 11:01 ` Qais Yousef
2020-10-02 18:07 ` Rob Clark
2020-10-05 15:00 ` Qais Yousef
2020-10-05 23:24 ` Rob Clark
2020-10-06 9:08 ` Daniel Vetter
2020-10-06 10:01 ` Peter Zijlstra
2020-10-06 10:59 ` Qais Yousef
2020-10-06 20:04 ` Rob Clark
2020-10-07 10:36 ` Qais Yousef
2020-10-07 15:57 ` Rob Clark
2020-10-07 16:30 ` Qais Yousef
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=20201002110544.GB6112@intel.com \
--to=ville.syrjala@linux.intel.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=robdclark@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).