From: Mel Gorman <mgorman@suse.de> To: Phil Auld <pauld@redhat.com> Cc: Colin Ian King <colin.king@canonical.com>, Peter Zijlstra <peterz@infradead.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Giovanni Gherdovich <ggherdovich@suse.com>, Viresh Kumar <viresh.kumar@linaro.org>, Julia Lawall <julia.lawall@inria.fr>, Ingo Molnar <mingo@redhat.com>, kernel-janitors@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 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 <Gilles.Muller@inria.fr>, srinivas.pandruvada@linux.intel.com, Linux PM <linux-pm@vger.kernel.org>, Len Brown <len.brown@intel.com> Subject: Re: default cpufreq gov, was: [PATCH] sched/fair: check for idle core Date: Thu, 22 Oct 2020 17:35:10 +0100 [thread overview] Message-ID: <20201022163509.GM32041@suse.de> (raw) In-Reply-To: <20201022151200.GC92942@lorien.usersys.redhat.com> On Thu, Oct 22, 2020 at 11:12:00AM -0400, Phil Auld wrote: > > > AFAIK, not quite (added Giovanni as he has been paying more attention). > > > Schedutil has improved since it was merged but not to the extent where > > > it is a drop-in replacement. The standard it needs to meet is that > > > it is at least equivalent to powersave (in intel_pstate language) > > > or ondemand (acpi_cpufreq) and within a reasonable percentage of the > > > performance governor. Defaulting to performance is a) giving up and b) > > > the performance governor is not a universal win. There are some questions > > > currently on whether schedutil is good enough when HWP is not available. > > > There was some evidence (I don't have the data, Giovanni was looking into > > > it) that HWP was a requirement to make schedutil work well. That is a > > > hazard in itself because someone could test on the latest gen Intel CPU > > > and conclude everything is fine and miss that Intel-specific technology > > > is needed to make it work well while throwing everyone else under a bus. > > > Giovanni knows a lot more than I do about this, I could be wrong or > > > forgetting things. > > > > > > For distros, switching to schedutil by default would be nice because > > > frequency selection state would follow the task instead of being per-cpu > > > and we could stop worrying about different HWP implementations but it's > > > not at the point where the switch is advisable. I would expect hard data > > > before switching the default and still would strongly advise having a > > > period of time where we can fall back when someone inevitably finds a > > > new corner case or exception. > > > > ..and it would be really useful for distros to know when the hard data > > is available so that they can make an informed decision when to move to > > schedutil. > > > > I think distros are on the hook to generate that hard data themselves > with which to make such a decision. I don't expect it to be done by > someone else. > Yep, distros are on the hook. When I said "I would expect hard data", it was in the knowledge that for openSUSE/SLE, we (as in SUSE) would be generating said data and making a call based on it. I'd be surprised if Phil was not thinking along the same lines. > > > For reference, SLUB had the same problem for years. It was switched > > > on by default in the kernel config but it was a long time before > > > SLUB was generally equivalent to SLAB in terms of performance. Block > > > multiqueue also had vaguely similar issues before the default changes > > > and a period of time before it was removed removed (example whinging mail > > > https://lore.kernel.org/lkml/20170803085115.r2jfz2lofy5spfdb@techsingularity.net/) > > > It's schedutil's turn :P > > > > > > > Agreed. I'd like the option to switch back if we make the default change. > It's on the table and I'd like to be able to go that way. > Yep. It sounds chicken, but it's a useful safety net and a reasonable way to deprecate a feature. It's also useful for bug creation -- User X running whatever found that schedutil is worse than the old governor and had to temporarily switch back. Repeat until complaining stops and then tear out the old stuff. When/if there is a patch setting schedutil as the default, cc suitable distro people (Giovanni and myself for openSUSE). Other distros assuming they're watching can nominate their own victim. -- Mel Gorman SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de> To: Phil Auld <pauld@redhat.com> Cc: Colin Ian King <colin.king@canonical.com>, Peter Zijlstra <peterz@infradead.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Giovanni Gherdovich <ggherdovich@suse.com>, Viresh Kumar <viresh.kumar@linaro.org>, Julia Lawall <julia.lawall@inria.fr>, Ingo Molnar <mingo@redhat.com>, kernel-janitors@vger.kernel.org, Juri Lelli <juri.lelli@redhat.com>, Vincent Guittot <vincent.guittot@linaro.org>, 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 <Gilles.Muller@inria.fr>, srinivas.pandruvada@linux.intel.com, Linux PM <linux-pm@vger.kernel.org>, Len Brown <len.brown@intel.com> Subject: Re: default cpufreq gov, was: [PATCH] sched/fair: check for idle core Date: Thu, 22 Oct 2020 16:35:10 +0000 [thread overview] Message-ID: <20201022163509.GM32041@suse.de> (raw) In-Reply-To: <20201022151200.GC92942@lorien.usersys.redhat.com> On Thu, Oct 22, 2020 at 11:12:00AM -0400, Phil Auld wrote: > > > AFAIK, not quite (added Giovanni as he has been paying more attention). > > > Schedutil has improved since it was merged but not to the extent where > > > it is a drop-in replacement. The standard it needs to meet is that > > > it is at least equivalent to powersave (in intel_pstate language) > > > or ondemand (acpi_cpufreq) and within a reasonable percentage of the > > > performance governor. Defaulting to performance is a) giving up and b) > > > the performance governor is not a universal win. There are some questions > > > currently on whether schedutil is good enough when HWP is not available. > > > There was some evidence (I don't have the data, Giovanni was looking into > > > it) that HWP was a requirement to make schedutil work well. That is a > > > hazard in itself because someone could test on the latest gen Intel CPU > > > and conclude everything is fine and miss that Intel-specific technology > > > is needed to make it work well while throwing everyone else under a bus. > > > Giovanni knows a lot more than I do about this, I could be wrong or > > > forgetting things. > > > > > > For distros, switching to schedutil by default would be nice because > > > frequency selection state would follow the task instead of being per-cpu > > > and we could stop worrying about different HWP implementations but it's > > > not at the point where the switch is advisable. I would expect hard data > > > before switching the default and still would strongly advise having a > > > period of time where we can fall back when someone inevitably finds a > > > new corner case or exception. > > > > ..and it would be really useful for distros to know when the hard data > > is available so that they can make an informed decision when to move to > > schedutil. > > > > I think distros are on the hook to generate that hard data themselves > with which to make such a decision. I don't expect it to be done by > someone else. > Yep, distros are on the hook. When I said "I would expect hard data", it was in the knowledge that for openSUSE/SLE, we (as in SUSE) would be generating said data and making a call based on it. I'd be surprised if Phil was not thinking along the same lines. > > > For reference, SLUB had the same problem for years. It was switched > > > on by default in the kernel config but it was a long time before > > > SLUB was generally equivalent to SLAB in terms of performance. Block > > > multiqueue also had vaguely similar issues before the default changes > > > and a period of time before it was removed removed (example whinging mail > > > https://lore.kernel.org/lkml/20170803085115.r2jfz2lofy5spfdb@techsingularity.net/) > > > It's schedutil's turn :P > > > > > > > Agreed. I'd like the option to switch back if we make the default change. > It's on the table and I'd like to be able to go that way. > Yep. It sounds chicken, but it's a useful safety net and a reasonable way to deprecate a feature. It's also useful for bug creation -- User X running whatever found that schedutil is worse than the old governor and had to temporarily switch back. Repeat until complaining stops and then tear out the old stuff. When/if there is a patch setting schedutil as the default, cc suitable distro people (Giovanni and myself for openSUSE). Other distros assuming they're watching can nominate their own victim. -- Mel Gorman SUSE Labs
next prev parent reply other threads:[~2020-10-22 16:35 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 [this message] 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 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=20201022163509.GM32041@suse.de \ --to=mgorman@suse.de \ --cc=Gilles.Muller@inria.fr \ --cc=bristot@redhat.com \ --cc=bsegall@google.com \ --cc=colin.king@canonical.com \ --cc=dietmar.eggemann@arm.com \ --cc=ggherdovich@suse.com \ --cc=julia.lawall@inria.fr \ --cc=juri.lelli@redhat.com \ --cc=kernel-janitors@vger.kernel.org \ --cc=len.brown@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=pauld@redhat.com \ --cc=peterz@infradead.org \ --cc=rjw@rjwysocki.net \ --cc=rostedt@goodmis.org \ --cc=srinivas.pandruvada@linux.intel.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.