All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 20 Sep 2024 16:17:32 +0000	[thread overview]
Message-ID: <Zu2gHOv7mqArWXLZ@google.com> (raw)
In-Reply-To: <20240830130309.2141697-5-vincent.guittot@linaro.org>

Hi Vincent,

On Friday 30 Aug 2024 at 15:03:08 (+0200), Vincent Guittot wrote:
> Keep looking for an energy efficient CPU even when the system is
> overutilized and use the CPU returned by feec() if it has been able to find
> one. Otherwise fallback to the default performance and spread mode of the
> scheduler.
> A system can become overutilized for a short time when workers of a
> workqueue wake up for a short background work like vmstat update.
> Continuing to look for a energy efficient CPU will prevent to break the
> power packing of tasks.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
>  kernel/sched/fair.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 2273eecf6086..e46af2416159 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8505,7 +8505,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int wake_flags)
>  		    cpumask_test_cpu(cpu, p->cpus_ptr))
>  			return cpu;
>  
> -		if (!is_rd_overutilized(this_rq()->rd)) {
> +		if (sched_energy_enabled()) {

As mentioned during LPC, when there is no idle time on a CPU, the
utilization value of the tasks running on it is no longer a good
approximation for how much the tasks want, it becomes an image of how
much CPU time they were given. That is particularly problematic in the
co-scheduling case, but not just.

IOW, when we're OU, the util values are bogus, so using feec() is frankly
wrong IMO. If we don't have a good idea of how long tasks want to run,
the EM just can't help us with anything so we should stay away from it.

I understand how just plain bailing out as we do today is sub-optimal,
but whatever we do to improve on that can't be doing utilization-based
task placement.

Have you considered making the default (non-EAS) wake-up path a little
more reluctant to migrations when EAS is enabled? That should allow us
to maintain a somewhat stable task placement when OU is only transient
(e.g. due to misfit), but without using util values when we really
shouldn't.

Thoughts?

Thanks,
Quentin

>  			new_cpu = find_energy_efficient_cpu(p, prev_cpu);
>  			if (new_cpu >= 0)
>  				return new_cpu;
> -- 
> 2.34.1
> 
> 

  parent reply	other threads:[~2024-09-20 16:17 UTC|newest]

Thread overview: 64+ 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 [this message]
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
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-02  8:00   ` kernel test robot
2024-09-02  8:30   ` kernel test robot
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=Zu2gHOv7mqArWXLZ@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 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.