From: Vincent Guittot <vincent.guittot@linaro.org> To: Mel Gorman <mgorman@suse.de> Cc: Julia Lawall <julia.lawall@inria.fr>, 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 <linux-kernel@vger.kernel.org>, Valentin Schneider <valentin.schneider@arm.com>, Gilles Muller <Gilles.Muller@inria.fr> Subject: Re: [PATCH] sched/fair: check for idle core Date: Wed, 21 Oct 2020 17:19:53 +0200 [thread overview] Message-ID: <CAKfTPtDs1t6mt7fPgoGg+fT-JKmaqWybNVBN3kZhag6M4+8RUg@mail.gmail.com> (raw) In-Reply-To: <20201021150800.GG32041@suse.de> On Wed, 21 Oct 2020 at 17:08, Mel Gorman <mgorman@suse.de> wrote: > > On Wed, Oct 21, 2020 at 03:24:48PM +0200, Julia Lawall wrote: > > > 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. > > > > But it is equal to the original behavior in the idle prev case if you go > > back to the runnable load average days... > > > > It is similar but it misses the sync treatment and sd->imbalance_pct part of > wake_affine_weight which has unpredictable consequences. The data > available is only on the fully utilised case. In fact It's the same because runnable_load_avg was null when cpu is idle, so if prev_cpu was idle, we were selecting prev_idle > > > The problem seems impossible to solve, because there is no way to know by > > looking only at prev and this whether the thread would prefer to stay > > where it was or go to the waker. > > > > Yes, this is definitely true. Looking at prev_cpu and this_cpu is a > crude approximation and the path is heavily limited in terms of how > clever it can be. > > -- > Mel Gorman > SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Vincent Guittot <vincent.guittot@linaro.org> To: Mel Gorman <mgorman@suse.de> Cc: Julia Lawall <julia.lawall@inria.fr>, 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 <linux-kernel@vger.kernel.org>, Valentin Schneider <valentin.schneider@arm.com>, Gilles Muller <Gilles.Muller@inria.fr> Subject: Re: [PATCH] sched/fair: check for idle core Date: Wed, 21 Oct 2020 15:19:53 +0000 [thread overview] Message-ID: <CAKfTPtDs1t6mt7fPgoGg+fT-JKmaqWybNVBN3kZhag6M4+8RUg@mail.gmail.com> (raw) In-Reply-To: <20201021150800.GG32041@suse.de> On Wed, 21 Oct 2020 at 17:08, Mel Gorman <mgorman@suse.de> wrote: > > On Wed, Oct 21, 2020 at 03:24:48PM +0200, Julia Lawall wrote: > > > 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. > > > > But it is equal to the original behavior in the idle prev case if you go > > back to the runnable load average days... > > > > It is similar but it misses the sync treatment and sd->imbalance_pct part of > wake_affine_weight which has unpredictable consequences. The data > available is only on the fully utilised case. In fact It's the same because runnable_load_avg was null when cpu is idle, so if prev_cpu was idle, we were selecting prev_idle > > > The problem seems impossible to solve, because there is no way to know by > > looking only at prev and this whether the thread would prefer to stay > > where it was or go to the waker. > > > > Yes, this is definitely true. Looking at prev_cpu and this_cpu is a > crude approximation and the path is heavily limited in terms of how > clever it can be. > > -- > Mel Gorman > SUSE Labs
next prev parent reply other threads:[~2020-10-21 15:20 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 [this message] 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 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=CAKfTPtDs1t6mt7fPgoGg+fT-JKmaqWybNVBN3kZhag6M4+8RUg@mail.gmail.com \ --to=vincent.guittot@linaro.org \ --cc=Gilles.Muller@inria.fr \ --cc=bristot@redhat.com \ --cc=bsegall@google.com \ --cc=dietmar.eggemann@arm.com \ --cc=julia.lawall@inria.fr \ --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 \ /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: linkBe 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.