From: Quentin Perret <quentin.perret@arm.com> To: Vincent Guittot <vincent.guittot@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, linux-kernel <linux-kernel@vger.kernel.org>, "open list:THERMAL" <linux-pm@vger.kernel.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@redhat.com>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Morten Rasmussen <morten.rasmussen@arm.com>, Chris Redpath <chris.redpath@arm.com>, Patrick Bellasi <patrick.bellasi@arm.com>, Valentin Schneider <valentin.schneider@arm.com>, Thara Gopinath <thara.gopinath@linaro.org>, viresh kumar <viresh.kumar@linaro.org>, Todd Kjos <tkjos@google.com>, Joel Fernandes <joel@joelfernandes.org>, "Cc: Steve Muckle" <smuckle@google.com>, adharmap@quicinc.com, "Kannan, Saravana" <skannan@quicinc.com>, pkondeti@codeaurora.org, Juri Lelli <juri.lelli@redhat.com>, Eduardo Valentin <edubezval@gmail.com>, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>, currojerez@riseup.net, Javi Merino <javi.merino@kernel.org> Subject: Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator Date: Mon, 6 Aug 2018 10:43:43 +0100 [thread overview] Message-ID: <20180806094342.lonjz4g3lspcatcy@queper01-lin> (raw) In-Reply-To: <CAKfTPtBT-p-Z0EneirfOTwUw=5jEeDGa+4_EE4ogi2Ht7GU9Bg@mail.gmail.com> On Monday 06 Aug 2018 at 10:40:46 (+0200), Vincent Guittot wrote: > On Fri, 3 Aug 2018 at 17:55, Quentin Perret <quentin.perret@arm.com> wrote: > For every new task, the cpu selection is done assuming it's a heavy > task with the max possible load_avg, and it looks for the idlest cpu. > This means that if the system is lightly loaded, scheduler will select > most probably a idle big core. Agreed, that is what should happen if the system is lightly loaded. However, I'm still not totally convinced this is wrong. It's definitely not _always_ wrong, at least. Just like starting new tasks on little CPUs isn't always wrong either. > selecting big or Little is not the problem here. The problem is that > we don't use Energy Model so we will most probably do the wrong > choice. Nevertheless, putting a task on big is clearly the wrong > choice in the case I mentioned above " shell script on hikey960". _You_ can say it's wrong because _you_ know the task composition. The scheduler has no way to tell. You could come up with a script that spawns heavy tasks every once in a while, and in this case putting those on big cores would be beneficial ... > Having something in the middle like taking into account load and/org > utilization of the parent in order to mitigate big task starting with > small utilization and small task starting with big utilization. > It's probably not perfect because big tasks can create small ones and > the opposite but if there are already big tasks, assuming that the new > one is also a big one should have less power impact as we are already > consuming power for the current bigs. At the opposite, if little are > running, assuming that new task is little will not harm the power > consumption unnecessarily. Right, we can definitely come up with something more conservative than what I'm currently proposing. I had a quick chat with Morten about this the other day and one suggestion he had was to pick the CPU with the max spare cap in the frequency domain in which the parent task is running ... In any case, I really feel like there isn't an obvious right decision here, so I'd prefer to keep things simple for now. This patch-set is a first step, and fine-grained tuning for new tasks is probably something that can be done later, if need be. What do you think ? Thanks, Quentin
WARNING: multiple messages have this Message-ID (diff)
From: Quentin Perret <quentin.perret@arm.com> To: Vincent Guittot <vincent.guittot@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, linux-kernel <linux-kernel@vger.kernel.org>, "open list:THERMAL" <linux-pm@vger.kernel.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, Ingo Molnar <mingo@redhat.com>, Dietmar Eggemann <dietmar.eggemann@arm.com>, Morten Rasmussen <morten.rasmussen@arm.com>, Chris Redpath <chris.redpath@arm.com>, Patrick Bellasi <patrick.bellasi@arm.com>, Valentin Schneider <valentin.schneider@arm.com>, Thara Gopinath <thara.gopinath@linaro.org>, viresh kumar <viresh.kumar@linaro.org>, Todd Kjos <tkjos@google.com>, Joel Fernandes <joel@joelfernandes.org>, "Cc: Steve Muckle" <smuckle@google.com>, adharmap@quicinc.com, "Kannan, Saravana" <skannan@quicinc.com>, pkondeti@codeaurora.org Subject: Re: [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator Date: Mon, 6 Aug 2018 10:43:43 +0100 [thread overview] Message-ID: <20180806094342.lonjz4g3lspcatcy@queper01-lin> (raw) In-Reply-To: <CAKfTPtBT-p-Z0EneirfOTwUw=5jEeDGa+4_EE4ogi2Ht7GU9Bg@mail.gmail.com> On Monday 06 Aug 2018 at 10:40:46 (+0200), Vincent Guittot wrote: > On Fri, 3 Aug 2018 at 17:55, Quentin Perret <quentin.perret@arm.com> wrote: > For every new task, the cpu selection is done assuming it's a heavy > task with the max possible load_avg, and it looks for the idlest cpu. > This means that if the system is lightly loaded, scheduler will select > most probably a idle big core. Agreed, that is what should happen if the system is lightly loaded. However, I'm still not totally convinced this is wrong. It's definitely not _always_ wrong, at least. Just like starting new tasks on little CPUs isn't always wrong either. > selecting big or Little is not the problem here. The problem is that > we don't use Energy Model so we will most probably do the wrong > choice. Nevertheless, putting a task on big is clearly the wrong > choice in the case I mentioned above " shell script on hikey960". _You_ can say it's wrong because _you_ know the task composition. The scheduler has no way to tell. You could come up with a script that spawns heavy tasks every once in a while, and in this case putting those on big cores would be beneficial ... > Having something in the middle like taking into account load and/org > utilization of the parent in order to mitigate big task starting with > small utilization and small task starting with big utilization. > It's probably not perfect because big tasks can create small ones and > the opposite but if there are already big tasks, assuming that the new > one is also a big one should have less power impact as we are already > consuming power for the current bigs. At the opposite, if little are > running, assuming that new task is little will not harm the power > consumption unnecessarily. Right, we can definitely come up with something more conservative than what I'm currently proposing. I had a quick chat with Morten about this the other day and one suggestion he had was to pick the CPU with the max spare cap in the frequency domain in which the parent task is running ... In any case, I really feel like there isn't an obvious right decision here, so I'd prefer to keep things simple for now. This patch-set is a first step, and fine-grained tuning for new tasks is probably something that can be done later, if need be. What do you think ? Thanks, Quentin
next prev parent reply other threads:[~2018-08-06 9:43 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-24 12:25 [PATCH v5 00/14] Energy Aware Scheduling Quentin Perret 2018-07-24 12:25 ` [PATCH v5 01/14] sched: Relocate arch_scale_cpu_capacity Quentin Perret 2018-07-24 12:25 ` [PATCH v5 02/14] sched/cpufreq: Factor out utilization to frequency mapping Quentin Perret 2018-07-24 12:25 ` [PATCH v5 03/14] PM: Introduce an Energy Model management framework Quentin Perret 2018-08-09 21:52 ` Rafael J. Wysocki 2018-08-10 8:15 ` Quentin Perret 2018-08-10 8:41 ` Rafael J. Wysocki 2018-08-10 8:41 ` Rafael J. Wysocki 2018-08-10 9:12 ` Quentin Perret 2018-08-10 11:13 ` Rafael J. Wysocki 2018-08-10 12:30 ` Quentin Perret 2018-08-12 9:49 ` Rafael J. Wysocki 2018-08-12 9:49 ` Rafael J. Wysocki 2018-07-24 12:25 ` [PATCH v5 04/14] PM / EM: Expose the Energy Model in sysfs Quentin Perret 2018-07-24 12:25 ` [PATCH v5 05/14] sched/topology: Reference the Energy Model of CPUs when available Quentin Perret 2018-07-24 12:25 ` [PATCH v5 06/14] sched/topology: Lowest energy aware balancing sched_domain level pointer Quentin Perret 2018-07-26 16:00 ` Valentin Schneider 2018-07-26 17:01 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 07/14] sched/topology: Introduce sched_energy_present static key Quentin Perret 2018-07-24 12:25 ` [PATCH v5 08/14] sched/fair: Clean-up update_sg_lb_stats parameters Quentin Perret 2018-07-24 12:25 ` [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator Quentin Perret 2018-08-02 12:26 ` Peter Zijlstra 2018-08-02 13:03 ` Quentin Perret 2018-08-02 13:08 ` Peter Zijlstra 2018-08-02 13:18 ` Quentin Perret 2018-08-02 13:48 ` Vincent Guittot 2018-08-02 13:48 ` Vincent Guittot 2018-08-02 14:14 ` Quentin Perret 2018-08-02 14:14 ` Quentin Perret 2018-08-02 15:14 ` Vincent Guittot 2018-08-02 15:14 ` Vincent Guittot 2018-08-02 15:30 ` Quentin Perret 2018-08-02 15:30 ` Quentin Perret 2018-08-02 15:55 ` Vincent Guittot 2018-08-02 15:55 ` Vincent Guittot 2018-08-02 16:00 ` Quentin Perret 2018-08-02 16:00 ` Quentin Perret 2018-08-02 16:07 ` Vincent Guittot 2018-08-02 16:07 ` Vincent Guittot 2018-08-02 16:10 ` Quentin Perret 2018-08-02 16:10 ` Quentin Perret 2018-08-02 16:38 ` Vincent Guittot 2018-08-02 16:38 ` Vincent Guittot 2018-08-02 16:59 ` Quentin Perret 2018-08-02 16:59 ` Quentin Perret 2018-08-03 7:48 ` Vincent Guittot 2018-08-03 7:48 ` Vincent Guittot 2018-08-03 8:18 ` Quentin Perret 2018-08-03 8:18 ` Quentin Perret 2018-08-03 13:49 ` Vincent Guittot 2018-08-03 13:49 ` Vincent Guittot 2018-08-03 14:21 ` Vincent Guittot 2018-08-03 14:21 ` Vincent Guittot 2018-08-03 15:55 ` Quentin Perret 2018-08-03 15:55 ` Quentin Perret 2018-08-06 8:40 ` Vincent Guittot 2018-08-06 8:40 ` Vincent Guittot 2018-08-06 9:43 ` Quentin Perret [this message] 2018-08-06 9:43 ` Quentin Perret 2018-08-06 10:45 ` Vincent Guittot 2018-08-06 10:45 ` Vincent Guittot 2018-08-06 11:02 ` Quentin Perret 2018-08-06 11:02 ` Quentin Perret 2018-08-06 10:08 ` Dietmar Eggemann 2018-08-06 10:08 ` Dietmar Eggemann 2018-08-06 10:33 ` Vincent Guittot 2018-08-06 10:33 ` Vincent Guittot 2018-08-06 12:29 ` Dietmar Eggemann 2018-08-06 12:29 ` Dietmar Eggemann 2018-08-06 12:37 ` Vincent Guittot 2018-08-06 12:37 ` Vincent Guittot 2018-08-06 13:20 ` Dietmar Eggemann 2018-08-06 13:20 ` Dietmar Eggemann 2018-08-09 9:30 ` Vincent Guittot 2018-08-09 9:30 ` Vincent Guittot 2018-08-09 9:38 ` Quentin Perret 2018-08-09 9:38 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method Quentin Perret 2018-07-30 19:35 ` skannan 2018-07-31 7:59 ` Quentin Perret 2018-07-31 19:31 ` skannan 2018-08-01 7:32 ` Rafael J. Wysocki 2018-08-01 7:32 ` Rafael J. Wysocki 2018-08-01 8:23 ` Quentin Perret 2018-08-01 8:23 ` Quentin Perret 2018-08-01 8:35 ` Rafael J. Wysocki 2018-08-01 8:35 ` Rafael J. Wysocki 2018-08-01 9:23 ` Quentin Perret 2018-08-01 9:23 ` Quentin Perret 2018-08-01 9:40 ` Rafael J. Wysocki 2018-08-01 9:40 ` Rafael J. Wysocki 2018-08-02 13:04 ` Peter Zijlstra 2018-08-02 13:04 ` Peter Zijlstra 2018-08-02 15:39 ` Quentin Perret 2018-08-02 15:39 ` Quentin Perret 2018-08-03 13:04 ` Quentin Perret 2018-08-03 13:04 ` Quentin Perret 2018-08-02 12:33 ` Peter Zijlstra 2018-08-02 12:45 ` Peter Zijlstra 2018-08-02 15:21 ` Quentin Perret 2018-08-02 17:36 ` Peter Zijlstra 2018-08-03 12:42 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 11/14] sched/fair: Introduce an energy estimation helper function Quentin Perret 2018-07-24 12:25 ` [PATCH v5 12/14] sched/fair: Select an energy-efficient CPU on task wake-up Quentin Perret 2018-08-02 13:54 ` Peter Zijlstra 2018-08-02 16:21 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 13/14] OPTIONAL: arch_topology: Start Energy Aware Scheduling Quentin Perret 2018-07-24 12:25 ` [PATCH v5 14/14] OPTIONAL: cpufreq: dt: Register an Energy Model Quentin Perret
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=20180806094342.lonjz4g3lspcatcy@queper01-lin \ --to=quentin.perret@arm.com \ --cc=adharmap@quicinc.com \ --cc=chris.redpath@arm.com \ --cc=currojerez@riseup.net \ --cc=dietmar.eggemann@arm.com \ --cc=edubezval@gmail.com \ --cc=gregkh@linuxfoundation.org \ --cc=javi.merino@kernel.org \ --cc=joel@joelfernandes.org \ --cc=juri.lelli@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=morten.rasmussen@arm.com \ --cc=patrick.bellasi@arm.com \ --cc=peterz@infradead.org \ --cc=pkondeti@codeaurora.org \ --cc=rjw@rjwysocki.net \ --cc=skannan@quicinc.com \ --cc=smuckle@google.com \ --cc=srinivas.pandruvada@linux.intel.com \ --cc=thara.gopinath@linaro.org \ --cc=tkjos@google.com \ --cc=valentin.schneider@arm.com \ --cc=vincent.guittot@linaro.org \ --cc=viresh.kumar@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: 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.