From: Quentin Perret <qperret@google.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
lukasz.luba@arm.com, rafael.j.wysocki@intel.com,
linux-kernel@vger.kernel.org, qyousef@layalina.io,
hongyan.xia2@arm.com
Subject: Re: [RFC PATCH 4/5] sched/fair: Use EAS also when overutilized
Date: Thu, 3 Oct 2024 09:52:09 +0000 [thread overview]
Message-ID: <Zv5pSdRsSsfRSNsJ@google.com> (raw)
In-Reply-To: <CAKfTPtAmgi0QbtjqjJ_mzq6qat8ivd3vXXNYMiniDeKvLwujDQ@mail.gmail.com>
On Thursday 03 Oct 2024 at 10:57:55 (+0200), Vincent Guittot wrote:
> The current pelt algorithm track actual cpu utilization and can go
> above cpu capacity (but not above 1024) so a task utilization can
> become bigger than a little cpu capacity
Right, the time invariance thing. So yes, I still think that a mix of
co-scheduling and task migrations (which is likely common in the
overcommitted state) will cause some CPUs to appear lightly utilized at
least transiently, hence tricking feec() into thinking it can help when
it really can't.
> As replied to Lukasz, if you want to discard utilization of a trask
> you need to check the previous cpu
Please help me out here because I'm still not quite sure what we're
talking about. Could you please expand a bit?
Thanks,
Quentin
next prev parent reply other threads:[~2024-10-03 9:52 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 13:03 [PATCH 0/5] sched/fair: Rework EAS to handle more cases Vincent Guittot
2024-08-30 13:03 ` [PATCH 1/5] sched/fair: Filter false overloaded_group case for EAS Vincent Guittot
2024-09-02 9:01 ` Hongyan Xia
2024-09-06 6:51 ` Vincent Guittot
2024-09-13 13:21 ` Pierre Gondois
2024-08-30 13:03 ` [PATCH 2/5] energy model: Add a get previous state function Vincent Guittot
2024-09-05 9:21 ` Lukasz Luba
2024-09-06 6:55 ` Vincent Guittot
2024-08-30 13:03 ` [PATCH 3/5] sched/fair: Rework feec() to use cost instead of spare capacity Vincent Guittot
2024-09-02 9:11 ` kernel test robot
2024-09-02 11:03 ` Hongyan Xia
2024-09-06 7:08 ` Vincent Guittot
2024-09-06 15:32 ` Hongyan Xia
2024-09-12 12:12 ` Vincent Guittot
2024-09-04 15:07 ` Pierre Gondois
2024-09-06 7:08 ` Vincent Guittot
2024-09-11 14:02 ` Pierre Gondois
2024-09-11 16:51 ` Pierre Gondois
2024-09-12 12:22 ` Vincent Guittot
2024-12-05 16:23 ` Pierre Gondois
2024-08-30 13:03 ` [RFC PATCH 4/5] sched/fair: Use EAS also when overutilized Vincent Guittot
2024-09-17 20:24 ` Christian Loehle
2024-09-19 8:25 ` Pierre Gondois
2024-09-25 13:28 ` Vincent Guittot
2024-10-07 7:03 ` Pierre Gondois
2024-10-09 8:53 ` Vincent Guittot
2024-10-11 12:52 ` Pierre Gondois
2024-10-15 12:47 ` Vincent Guittot
2024-10-31 15:21 ` Pierre Gondois
2024-09-25 13:07 ` Vincent Guittot
2024-09-20 16:17 ` Quentin Perret
2024-09-25 13:27 ` Vincent Guittot
2024-09-26 9:10 ` Quentin Perret
2024-10-01 16:20 ` Vincent Guittot
2024-10-01 17:50 ` Quentin Perret
2024-10-02 7:11 ` Lukasz Luba
2024-10-02 7:55 ` Quentin Perret
2024-10-02 9:54 ` Lukasz Luba
2024-10-03 6:27 ` Vincent Guittot
2024-10-03 8:15 ` Lukasz Luba
2024-10-03 8:26 ` Quentin Perret
2024-10-03 8:52 ` Vincent Guittot
2024-10-03 8:21 ` Quentin Perret
2024-10-03 8:57 ` Vincent Guittot
2024-10-03 9:52 ` Quentin Perret [this message]
2024-10-03 13:26 ` Vincent Guittot
2024-11-19 14:46 ` Christian Loehle
2024-08-30 13:03 ` [RFC PATCH 5/5] sched/fair: Add push task callback for EAS Vincent Guittot
2024-09-09 9:59 ` Christian Loehle
2024-09-09 12:54 ` Vincent Guittot
2024-09-11 14:03 ` Pierre Gondois
2024-09-12 12:30 ` Vincent Guittot
2024-09-13 9:09 ` Pierre Gondois
2024-09-24 12:37 ` Vincent Guittot
2024-09-13 16:08 ` Pierre Gondois
2024-09-24 13:00 ` Vincent Guittot
2024-11-07 10:14 ` [PATCH 0/5] sched/fair: Rework EAS to handle more cases Pierre Gondois
2024-11-08 9:27 ` Vincent Guittot
2024-11-08 13:10 ` Pierre Gondois
2024-11-11 19:08 ` Vincent Guittot
2024-11-28 17:24 ` Hongyan Xia
2024-11-30 10:50 ` Vincent Guittot
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=Zv5pSdRsSsfRSNsJ@google.com \
--to=qperret@google.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=hongyan.xia2@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=rafael.j.wysocki@intel.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox