All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qais Yousef <qyousef@layalina.io>
To: Xuewen Yan <xuewen.yan94@gmail.com>
Cc: Xuewen Yan <xuewen.yan@unisoc.com>,
	vincent.guittot@linaro.org, mingo@redhat.com,
	peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com, vincent.donnefort@arm.com,
	ke.wang@unisoc.com, linux-kernel@vger.kernel.org,
	christian.loehle@arm.com
Subject: Re: [PATCH] sched/fair: Prevent cpu_busy_time from exceeding actual_cpu_capacity
Date: Wed, 19 Jun 2024 19:03:48 +0100	[thread overview]
Message-ID: <20240619180348.rp22d4ozb4emncuq@airbuntu> (raw)
In-Reply-To: <CAB8ipk_LXzkkGzT1SS6U8i4nW6j9coxeuwn6vuUFusCQcFM8zw@mail.gmail.com>

On 06/19/24 10:46, Xuewen Yan wrote:
> On Tue, Jun 18, 2024 at 10:58 PM Qais Yousef <qyousef@layalina.io> wrote:
> >
> > On 06/17/24 12:03, Qais Yousef wrote:
> >
> > > > Sorry, I miss the "fits_capacity() use capacity_of()", and without
> > > > uclamp_max, the rd is over-utilized,
> > > > and would not use feec().
> > > > But I notice the uclamp_max, if the rq's uclamp_max is smaller than
> > > > SCHED_CAPACITY_SCALE,
> > > > and is bigger than actual_cpu_capacity, the util_fits_cpu() would
> > > > return true, and the rd is not over-utilized.
> > > > Is this setting intentional?
> > >
> > > Hmm. To a great extent yes. We didn't want to take all types of rq pressure
> > > into account for uclamp_max. But this corner case could be debatable.
> > >
> > > Is this the source of your problem? If you change util_fits_cpu() to return
> > > false here, would this fix the problem you're seeing?
> >
> > FWIW, if this happens due to uclamp_max, then this patch to do the capping is
> > still needed.
> >
> > I think it's good to understand first how we end up in feec() when a CPU is
> > supposed to be overutlized. uclamp_max is the only way to override this
> > decision AFAICT..
> 
> Sorry for the late reply...
> In our own tree, we removed the check for rd overutil in feec(), so
> the above case often occurs.

Yeah, the current definition of overutilized is not good enough. So I can see
the need to do that..

> And now it seems that on the mainline, uclamp_max is the only way to
> override this.

Thanks for checking. Your patch is correct and if we combine this with another
patch to use get_actual_cpu_capacity() in util_fits_cpu(), they are good
improvements.

Are you still happy to send an updated patches?


Thanks!

--
Qais Yousef

  reply	other threads:[~2024-06-19 18:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06  7:06 [PATCH] sched/fair: Prevent cpu_busy_time from exceeding actual_cpu_capacity Xuewen Yan
2024-06-07  7:19 ` Dietmar Eggemann
2024-06-07  8:20   ` Xuewen Yan
2024-06-07 10:30     ` Dietmar Eggemann
2024-06-07 10:37       ` Xuewen Yan
2024-06-21 10:22         ` Dietmar Eggemann
2024-06-24  2:27           ` Xuewen Yan
2024-06-09 22:55 ` Qais Yousef
2024-06-12  8:11   ` Xuewen Yan
2024-06-16 22:20     ` Qais Yousef
2024-06-17  7:27       ` Xuewen Yan
2024-06-17 11:03         ` Qais Yousef
2024-06-18 14:58           ` Qais Yousef
2024-06-19  2:46             ` Xuewen Yan
2024-06-19 18:03               ` Qais Yousef [this message]
2024-06-20  3:08                 ` Xuewen Yan
2024-06-21 10:40               ` Dietmar Eggemann
2024-06-21 13:00                 ` Vincent Guittot
2024-06-24  2:35                   ` Xuewen Yan
2024-06-18 15:20           ` Vincent Guittot
2024-06-18 15:26             ` Qais Yousef
2024-06-17  9:07       ` Vincent Guittot
2024-06-17 10:53         ` Qais Yousef
2024-06-18 15:23           ` Vincent Guittot
2024-06-18 15:39             ` Qais Yousef
2024-06-18 21:05               ` Vincent Guittot
2024-06-19 18:01                 ` Qais Yousef
2024-06-19  3:05               ` Xuewen Yan
2024-06-19 18:10                 ` Qais Yousef
2024-06-20  7:45                   ` Vincent Guittot
2024-06-20 11:37                     ` Qais Yousef
2024-06-21  8:22                       ` Dietmar Eggemann
2024-06-11  9:08 ` Christian Loehle

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=20240619180348.rp22d4ozb4emncuq@airbuntu \
    --to=qyousef@layalina.io \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=ke.wang@unisoc.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.donnefort@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=xuewen.yan94@gmail.com \
    --cc=xuewen.yan@unisoc.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.