linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qais Yousef <qais.yousef@arm.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Tim Murray <timmurray@google.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Rob Clark <robdclark@chromium.org>,
	open list <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>
Subject: Re: [PATCH v2 0/3] drm: commit_work scheduling
Date: Wed, 7 Oct 2020 11:36:53 +0100	[thread overview]
Message-ID: <20201007103653.qjohhta7douhlb22@e107158-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAF6AEGu_V_EGcPQ+F_Z73cMCAcFPoM-GuiGWUPr+=6GD4Om=zg@mail.gmail.com>

On 10/06/20 13:04, Rob Clark wrote:
> On Tue, Oct 6, 2020 at 3:59 AM Qais Yousef <qais.yousef@arm.com> wrote:
> >
> > On 10/05/20 16:24, Rob Clark wrote:
> >
> > [...]
> >
> > > > RT planning and partitioning is not easy task for sure. You might want to
> > > > consider using affinities too to get stronger guarantees for some tasks and
> > > > prevent cross-talking.
> > >
> > > There is some cgroup stuff that is pinning SF and some other stuff to
> > > the small cores, fwiw.. I think the reasoning is that they shouldn't
> > > be doing anything heavy enough to need the big cores.
> >
> > Ah, so you're on big.LITTLE type of system. I have done some work which enables
> > biasing RT tasks towards big cores and control the default boost value if you
> > have util_clamp and schedutil enabled. You can use util_clamp in general to
> > help with DVFS related response time delays.
> >
> > I haven't done any work to try our best to pick a small core first but fallback
> > to big if there's no other alternative.
> >
> > It'd be interesting to know how often you end up on a big core if you remove
> > the affinity. The RT scheduler picks the first cpu in the lowest priority mask.
> > So it should have this bias towards picking smaller cores first if they're
> > in the lower priority mask (ie: not running higher priority RT tasks).
> 
> fwiw, the issue I'm looking at is actually at the opposite end of the
> spectrum, less demanding apps that let cpus throttle down to low
> OPPs.. which stretches out the time taken at each step in the path
> towards screen (which seems to improve the odds that we hit priority
> inversion scenarios with SCHED_FIFO things stomping on important CFS
> things)

So you do have the problem of RT task preempting an important CFS task.

> 
> There is a *big* difference in # of cpu cycles per frame between
> highest and lowest OPP..

To combat DVFS related delays, you can use util clamp.

Hopefully this article helps explain it if you didn't come across it before

	https://lwn.net/Articles/762043/

You can use sched_setattr() to set SCHED_FLAG_UTIL_CLAMP_MIN for a task. This
will guarantee everytime this task is running it'll appear it has at least
this utilization value, so schedutil governor (which must be used for this to
work) will pick up the right performance point (OPP).

The scheduler will try its best to make sure that the task will run on a core
that meets the minimum requested performance point (hinted by setting
uclamp_min).

Thanks

--
Qais Yousef

  reply	other threads:[~2020-10-07 10:36 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ä
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 [this message]
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=20201007103653.qjohhta7douhlb22@e107158-lin.cambridge.arm.com \
    --to=qais.yousef@arm.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=peterz@infradead.org \
    --cc=robdclark@chromium.org \
    --cc=robdclark@gmail.com \
    --cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).