All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qais Yousef <qais.yousef@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	linux-kernel@vger.kernel.org, Xuewen Yan <xuewen.yan94@gmail.com>,
	Wei Wang <wvw@google.com>,
	Jonathan JMChen <Jonathan.JMChen@mediatek.com>,
	Hank <han.lin@mediatek.com>, Lukasz Luba <lukasz.luba@arm.com>
Subject: Re: [PATCH 1/7] sched/uclamp: Fix relationship between uclamp and migration margin
Date: Fri, 15 Jul 2022 11:37:38 +0100	[thread overview]
Message-ID: <20220715103738.ufqv2nhkivlhzy7v@wubuntu> (raw)
In-Reply-To: <CAKfTPtB3pjoFWFP9E6RnH87nshEqJxPdFzX495R_Xju9rCPvEw@mail.gmail.com>

On 07/13/22 14:39, Vincent Guittot wrote:

[...]

> > > That's why I have mentioned that I have thermal pressure and irq in
> > > mind. I'm speaking about performance level but not about bandwidth and
> > > time sharing.
> >
> > irq pressure has no impact on the cpu's ability to get any OPP, no? It purely
> > reduces the bandwidth availability for CFS tasks AFAIU. So the task's ability
> > to achieve a performance level has no correlation with irq pressure IMO. Unless
> > I missed something.
> 
> The way irq is accounted in pelt might impact the result. TBH, i
> haven't looked in details what would be the impact

I can't see how irq can impact what performance level we can achieve on any
CPU. It should just impact bandwidth?

[...]

> > > more concerned by the thermal pressure as I mentioned previously. As
> > > an example the thermal pressure reflects the impact on the performance
> > > while task is running.
> >
> > Like we discussed on that RT email thread. If you have a 1024 task, tiny
> > thermal pressure will make it look like it won't fit anywhere.
> 
> maybe another big core without pressure. Otherwise if the task can

Isn't thermal pressure per perf domain?

> accept a lower compute capacity why not setting uclamp_min to a lower
> value like 900

Well if the system has lost its top 10% and you're still running as fast as
the system can possibly do, what better can you do?

I can't see how comparing uclamp with thermal pressure will help.

In feec() we pick the highest spare capacity CPU. So if the bigs were split
into 1 per perf domain and truly one of them can become severely throttled
while the other isn't as you're trying to say, then this distribution will pick
the highest spare capacity one.

fits_capacity() just says this CPU is a candidate that we can consider.

[...]

> > > TaskA usually runs 4 ms every 8ms but wants to ensure a running time
> > > around 5ms. Task A asks for a uclamp_min of 768.
> > > medium cpu capacity_orig is 800 but runs at half its max freq because
> > > of thermal mitigation then your task will runs more than 8ms
> >
> > If thermal pressure is 50%, then capacity_of() is 400. A 50% task will have
> > util_avg of 512, which is much larger than 0.8 * 400. So this is dealt with
> > already in this code, no?
> 
> May be my example is not perfect but apply a mitigation of 20% and you
> fall in the case

	capacity_orig_of(medium) = 800
	capacity_of(medium) = 800 * 0.8 - sum_of_(irq, rt) pressure :: <= 640

	migration_margin * capacity_of(medium) = 0.8 * 640 = 512 === p->util_avg

So this task will struggle still to run on the medium even under 20% pressure.

I can see your point for sure that we could have scenarios where we should pick
a bigger CPU. But my counter point is that if there's a meaningful thermal
pressure we are screwed already and uclamp can't save the day.

I'll repeat my question, how would you encode the relationship?

Consider these scenarios:


	capaity_orig_of(little) = 400
	capaity_orig_of(medium) = 800
	capaity_orig_of(big) = 1024

	p0->util_avg = 300
	p0->uclamp_min = 800

	p1->util_avg = 300
	p1->uclamp_min = 1024


When there's 10% thermal pressure on all CPUs.

Does p1 fit on big still? Fit here means the  big is a viable candidate from
uclamp point of view.

How would you define the relationship so that p0 will not fit the medium, but
p1 still fits the big.

What happens when thermal pressure is 1%? Should p0 still fit on the medium
then? As Lukasz highlighted in other email threads, the decay of thermal
pressure signal has a very long tail.


Thanks!

--
Qais Yousef

  reply	other threads:[~2022-07-15 10:37 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 19:46 [PATCH 0/7] Fix relationship between uclamp and fits_capacity() Qais Yousef
2022-06-29 19:46 ` [PATCH 1/7] sched/uclamp: Fix relationship between uclamp and migration margin Qais Yousef
2022-07-11 12:36   ` Vincent Guittot
2022-07-12 10:23     ` Qais Yousef
2022-07-12 13:21       ` Vincent Guittot
2022-07-12 14:20         ` Qais Yousef
2022-07-13 12:39           ` Vincent Guittot
2022-07-15 10:37             ` Qais Yousef [this message]
2022-07-20  7:29               ` Vincent Guittot
2022-07-21 14:04                 ` Qais Yousef
2022-07-22 15:13                   ` Vincent Guittot
2022-07-27 16:08                     ` Qais Yousef
2022-08-04 14:59                     ` Qais Yousef
2022-07-20  7:17   ` Xuewen Yan
2022-07-21 10:24     ` Qais Yousef
2022-07-25 11:59       ` Xuewen Yan
2022-07-27 16:25         ` Qais Yousef
2022-08-01  2:46           ` Xuewen Yan
2022-08-02 16:22             ` Qais Yousef
2022-06-29 19:46 ` [PATCH 2/7] sched/uclamp: Make task_fits_capacity() use util_fits_cpu() Qais Yousef
2022-07-11 13:09   ` Vincent Guittot
2022-07-12 10:48     ` Qais Yousef
2022-07-21 14:29       ` Qais Yousef
2022-07-22  8:19         ` Vincent Guittot
2022-07-27 16:05           ` Qais Yousef
2022-08-17  9:48             ` Vincent Guittot
2022-07-20  7:23   ` Xuewen Yan
2022-07-21 14:11     ` Qais Yousef
2022-06-29 19:46 ` [PATCH 3/7] sched/uclamp: Fix fits_capacity() check in feec() Qais Yousef
2022-07-20  7:30   ` Xuewen Yan
2022-07-21 14:19     ` Qais Yousef
2022-06-29 19:46 ` [PATCH 4/7] sched/uclamp: Make select_idle_capacity() use util_fits_cpu() Qais Yousef
2022-06-29 19:46 ` [PATCH 5/7] sched/uclamp: Make asym_fits_capacity() " Qais Yousef
2022-06-29 19:46 ` [PATCH 6/7] sched/uclamp: Make cpu_overutilized() " Qais Yousef
2022-06-29 19:46 ` [PATCH 7/7] sched/uclamp: Cater for uclamp in find_energy_efficient_cpu()'s early exit condition Qais Yousef
2022-07-20  7:39   ` Xuewen Yan
2022-07-21 14:24     ` Qais Yousef
2022-07-22  1:09       ` Xuewen Yan

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=20220715103738.ufqv2nhkivlhzy7v@wubuntu \
    --to=qais.yousef@arm.com \
    --cc=Jonathan.JMChen@mediatek.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=han.lin@mediatek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=vincent.guittot@linaro.org \
    --cc=wvw@google.com \
    --cc=xuewen.yan94@gmail.com \
    /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.