All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@inria.fr>
To: Mel Gorman <mgorman@suse.de>
Cc: Julia Lawall <julia.lawall@inria.fr>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	kernel-janitors@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	linux-kernel@vger.kernel.org,
	Valentin Schneider <valentin.schneider@arm.com>,
	Gilles.Muller@inria.fr
Subject: Re: [PATCH] sched/fair: check for idle core
Date: Wed, 21 Oct 2020 15:48:59 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2010211547190.57356@hadrien> (raw)
In-Reply-To: <20201021131827.GF32041@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]



On Wed, 21 Oct 2020, Mel Gorman wrote:

> On Wed, Oct 21, 2020 at 02:56:06PM +0200, Julia Lawall wrote:
> >
> >
> > On Wed, 21 Oct 2020, Mel Gorman wrote:
> >
> > > On Wed, Oct 21, 2020 at 02:25:32PM +0200, Vincent Guittot wrote:
> > > > > I see Vincent already agreed with the patch so I could be wrong.  Vincent,
> > > > > did I miss something stupid?
> > > >
> > > > This patch fixes the problem that we don't favor anymore the prev_cpu when it is idle since
> > > > commit 11f10e5420f6ce because load is not null when cpu is idle whereas runnable_load was
> > > > And this is important because this will then decide in which LLC we will looks for a cpu
> > > >
> > >
> > > Ok, that is understandable but I'm still concerned that the fix simply
> > > trades one problem for another by leaving related tasks remote to each
> > > other and increasing cache misses and remote data accesses.
> > >
> > > wake_affine_weight is a giant pain because really we don't care about the
> > > load on the waker CPU or its available, we care about whether it has idle
> > > siblings that can be found quickly. As tempting as ripping it out is,
> > > it never happened because sometimes it makes the right decision.
> >
> > My goal was to restore the previous behavior, when runnable load was used.
> > The patch removing the use of runnable load (11f10e5420f6) presented it
> > basically as that load balancing was using it, so wakeup should use it
> > too, and any way it didn't matter because idle CPUS were checked for
> > anyway.
> >
>
> Which is fair.
>
> > Is your point of view that the proposed change is overkill?  Or is it that
> > the original behavior was not desirable?
> >
>
> I worry it's overkill because prev is always used if it is idle even
> if it is on a node remote to the waker. It cuts off the option of a
> wakee moving to a CPU local to the waker which is not equivalent to the
> original behaviour.

Could it be possible to check p->recent_used_cpu?  If that is prev (or on
the same socket?), then prev could be a good choice.  If that is on the
same socket as the waker, then maybe the waker would be better.

julia

WARNING: multiple messages have this Message-ID (diff)
From: Julia Lawall <julia.lawall@inria.fr>
To: Mel Gorman <mgorman@suse.de>
Cc: Julia Lawall <julia.lawall@inria.fr>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	kernel-janitors@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	linux-kernel@vger.kernel.org,
	Valentin Schneider <valentin.schneider@arm.com>,
	Gilles.Muller@inria.fr
Subject: Re: [PATCH] sched/fair: check for idle core
Date: Wed, 21 Oct 2020 13:48:59 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2010211547190.57356@hadrien> (raw)
In-Reply-To: <20201021131827.GF32041@suse.de>

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]



On Wed, 21 Oct 2020, Mel Gorman wrote:

> On Wed, Oct 21, 2020 at 02:56:06PM +0200, Julia Lawall wrote:
> >
> >
> > On Wed, 21 Oct 2020, Mel Gorman wrote:
> >
> > > On Wed, Oct 21, 2020 at 02:25:32PM +0200, Vincent Guittot wrote:
> > > > > I see Vincent already agreed with the patch so I could be wrong.  Vincent,
> > > > > did I miss something stupid?
> > > >
> > > > This patch fixes the problem that we don't favor anymore the prev_cpu when it is idle since
> > > > commit 11f10e5420f6ce because load is not null when cpu is idle whereas runnable_load was
> > > > And this is important because this will then decide in which LLC we will looks for a cpu
> > > >
> > >
> > > Ok, that is understandable but I'm still concerned that the fix simply
> > > trades one problem for another by leaving related tasks remote to each
> > > other and increasing cache misses and remote data accesses.
> > >
> > > wake_affine_weight is a giant pain because really we don't care about the
> > > load on the waker CPU or its available, we care about whether it has idle
> > > siblings that can be found quickly. As tempting as ripping it out is,
> > > it never happened because sometimes it makes the right decision.
> >
> > My goal was to restore the previous behavior, when runnable load was used.
> > The patch removing the use of runnable load (11f10e5420f6) presented it
> > basically as that load balancing was using it, so wakeup should use it
> > too, and any way it didn't matter because idle CPUS were checked for
> > anyway.
> >
>
> Which is fair.
>
> > Is your point of view that the proposed change is overkill?  Or is it that
> > the original behavior was not desirable?
> >
>
> I worry it's overkill because prev is always used if it is idle even
> if it is on a node remote to the waker. It cuts off the option of a
> wakee moving to a CPU local to the waker which is not equivalent to the
> original behaviour.

Could it be possible to check p->recent_used_cpu?  If that is prev (or on
the same socket?), then prev could be a good choice.  If that is on the
same socket as the waker, then maybe the waker would be better.

julia

  parent reply	other threads:[~2020-10-21 13:49 UTC|newest]

Thread overview: 134+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-20 16:37 [PATCH] sched/fair: check for idle core Julia Lawall
2020-10-20 16:37 ` Julia Lawall
2020-10-21  7:29 ` Vincent Guittot
2020-10-21  7:29   ` Vincent Guittot
2020-10-21 11:13   ` Peter Zijlstra
2020-10-21 11:13     ` Peter Zijlstra
2020-10-21 12:27   ` Vincent Guittot
2020-10-21 12:27     ` Vincent Guittot
2020-10-21 11:20 ` Mel Gorman
2020-10-21 11:20   ` Mel Gorman
2020-10-21 11:56   ` Julia Lawall
2020-10-21 11:56     ` Julia Lawall
2020-10-21 12:19     ` Peter Zijlstra
2020-10-21 12:19       ` Peter Zijlstra
2020-10-21 12:42       ` Julia Lawall
2020-10-21 12:42         ` Julia Lawall
2020-10-21 12:52         ` Peter Zijlstra
2020-10-21 12:52           ` Peter Zijlstra
2020-10-21 13:43           ` Julia Lawall
2020-10-21 18:18           ` Rafael J. Wysocki
2020-10-21 18:18             ` Rafael J. Wysocki
2020-10-21 18:15         ` Rafael J. Wysocki
2020-10-21 18:15           ` Rafael J. Wysocki
2020-10-21 19:47           ` Julia Lawall
2020-10-21 19:47             ` Julia Lawall
2020-10-21 20:25             ` Rafael J. Wysocki
2020-10-21 20:25               ` Rafael J. Wysocki
2020-10-21 13:10       ` Peter Zijlstra
2020-10-21 13:10         ` Peter Zijlstra
2020-10-21 18:11         ` Rafael J. Wysocki
2020-10-21 18:11           ` Rafael J. Wysocki
2020-10-22  4:41           ` Viresh Kumar
2020-10-22  4:53             ` Viresh Kumar
2020-10-22  7:11           ` Peter Zijlstra
2020-10-22  7:11             ` Peter Zijlstra
2020-10-22 10:47             ` Viresh Kumar
2020-10-22 10:59               ` Viresh Kumar
2020-10-22 11:45               ` Rafael J. Wysocki
2020-10-22 11:45                 ` Rafael J. Wysocki
2020-10-22 12:02                 ` default cpufreq gov, was: " Peter Zijlstra
2020-10-22 12:02                   ` Peter Zijlstra
2020-10-22 12:19                   ` Rafael J. Wysocki
2020-10-22 12:19                     ` Rafael J. Wysocki
2020-10-22 12:29                     ` Peter Zijlstra
2020-10-22 12:29                       ` Peter Zijlstra
2020-10-22 14:52                       ` Mel Gorman
2020-10-22 14:52                         ` Mel Gorman
2020-10-22 14:58                         ` Colin Ian King
2020-10-22 14:58                           ` Colin Ian King
2020-10-22 15:12                           ` Phil Auld
2020-10-22 15:12                             ` Phil Auld
2020-10-22 16:35                             ` Mel Gorman
2020-10-22 16:35                               ` Mel Gorman
2020-10-22 17:59                               ` Rafael J. Wysocki
2020-10-22 17:59                                 ` Rafael J. Wysocki
2020-10-22 20:32                                 ` Mel Gorman
2020-10-22 20:32                                   ` Mel Gorman
2020-10-22 20:39                                   ` Phil Auld
2020-10-22 20:39                                     ` Phil Auld
2020-10-22 15:25                         ` Peter Zijlstra
2020-10-22 15:25                           ` Peter Zijlstra
2020-10-22 15:55                           ` Rafael J. Wysocki
2020-10-22 15:55                             ` Rafael J. Wysocki
2020-10-22 16:29                           ` Mel Gorman
2020-10-22 16:29                             ` Mel Gorman
2020-10-22 20:10                           ` Giovanni Gherdovich
2020-10-22 20:10                             ` Giovanni Gherdovich
2020-10-22 20:16                             ` Giovanni Gherdovich
2020-10-22 20:16                               ` Giovanni Gherdovich
2020-10-23  7:03                             ` Peter Zijlstra
2020-10-23  7:03                               ` Peter Zijlstra
2020-10-23 17:46                               ` Tom Lendacky
2020-10-23 17:46                                 ` Tom Lendacky
2020-10-26 19:52                                 ` Fontenot, Nathan
2020-10-26 19:52                                   ` Fontenot, Nathan
2020-10-22 15:45                       ` A L
2020-10-22 15:45                         ` A L
2020-10-22 15:55                         ` Vincent Guittot
2020-10-22 15:55                           ` Vincent Guittot
2020-10-23  5:11                           ` Viresh Kumar
2020-10-23  5:23                             ` Viresh Kumar
2020-10-22 16:23                   ` [PATCH] cpufreq: Avoid configuring old governors as default with intel_pstate Rafael J. Wysocki
2020-10-22 16:23                     ` Rafael J. Wysocki
2020-10-23  6:17                     ` Viresh Kumar
2020-10-23  6:29                       ` Viresh Kumar
2020-10-23 11:59                       ` Rafael J. Wysocki
2020-10-23 11:59                         ` Rafael J. Wysocki
2020-10-23 15:15                     ` [PATCH v2] " Rafael J. Wysocki
2020-10-23 15:15                       ` Rafael J. Wysocki
2020-10-27  3:01                       ` Viresh Kumar
2020-10-27  3:13                         ` Viresh Kumar
2020-10-27 11:11                   ` default cpufreq gov, was: [PATCH] sched/fair: check for idle core Qais Yousef
2020-10-27 11:26                     ` Valentin Schneider
2020-10-27 11:42                       ` Qais Yousef
2020-10-27 11:48                         ` Viresh Kumar
2020-10-27 11:48                           ` Viresh Kumar
2020-10-23  6:12                 ` Viresh Kumar
2020-10-23  6:24                   ` Viresh Kumar
2020-10-23 15:06                   ` Rafael J. Wysocki
2020-10-23 15:06                     ` Rafael J. Wysocki
2020-10-27  3:01                     ` Viresh Kumar
2020-10-27  3:13                       ` Viresh Kumar
2020-10-22 11:21             ` AW: " Walter Harms
2020-10-22 11:21               ` Walter Harms
2020-10-21 12:28     ` Mel Gorman
2020-10-21 12:28       ` Mel Gorman
2020-10-21 12:25   ` Vincent Guittot
2020-10-21 12:25     ` Vincent Guittot
2020-10-21 12:47     ` Mel Gorman
2020-10-21 12:47       ` Mel Gorman
2020-10-21 12:56       ` Julia Lawall
2020-10-21 12:56         ` Julia Lawall
2020-10-21 13:18         ` Mel Gorman
2020-10-21 13:18           ` Mel Gorman
2020-10-21 13:24           ` Julia Lawall
2020-10-21 13:24             ` Julia Lawall
2020-10-21 15:08             ` Mel Gorman
2020-10-21 15:08               ` Mel Gorman
2020-10-21 15:18               ` Julia Lawall
2020-10-21 15:18                 ` Julia Lawall
2020-10-21 15:23                 ` Vincent Guittot
2020-10-21 15:23                   ` Vincent Guittot
2020-10-21 15:33                   ` Julia Lawall
2020-10-21 15:33                     ` Julia Lawall
2020-10-21 15:19               ` Vincent Guittot
2020-10-21 15:19                 ` Vincent Guittot
2020-10-21 17:00                 ` Mel Gorman
2020-10-21 17:00                   ` Mel Gorman
2020-10-21 17:39                   ` Julia Lawall
2020-10-21 17:39                     ` Julia Lawall
2020-10-21 13:48           ` Julia Lawall [this message]
2020-10-21 13:48             ` Julia Lawall
2020-10-21 15:26             ` Mel Gorman
2020-10-21 15:26               ` Mel Gorman

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=alpine.DEB.2.22.394.2010211547190.57356@hadrien \
    --to=julia.lawall@inria.fr \
    --cc=Gilles.Muller@inria.fr \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.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 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.