From: Viresh Kumar <viresh.kumar@linaro.org> To: Morten Rasmussen <morten.rasmussen@arm.com> Cc: Saravana Kannan <skannan@codeaurora.org>, Dietmar Eggemann <dietmar.eggemann@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Linux PM list <linux-pm@vger.kernel.org>, Russell King <linux@arm.linux.org.uk>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Russell King <rmk+kernel@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will.deacon@arm.com>, Juri Lelli <juri.lelli@arm.com>, Vincent Guittot <vincent.guittot@linaro.org>, Peter Zijlstra <peterz@infradead.org> Subject: Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support Date: Thu, 22 Jun 2017 09:36:43 +0530 [thread overview] Message-ID: <20170622040643.GB6314@vireshk-i7> (raw) In-Reply-To: <20170621165714.GB2551@e105550-lin.cambridge.arm.com> On 21-06-17, 17:57, Morten Rasmussen wrote: > It is true that this patch relies on the notifiers, but I don't see how > that prevents us from adding a non-notifier based solution for > fast-switch enabled platforms later? No it doesn't, but I thought it would be better to have a single solution (if possible) for all the cases here. > > I think this patch doesn't really need to go down the notifiers way. > > > > We can do something like this in the implementation of > > topology_get_freq_scale(): > > > > return (policy->cur << SCHED_CAPACITY_SHIFT) / max; > > > > Though, we would be required to take care of policy structure in this > > case somehow. > > This is exactly what this patch implements. Unfortunately we can't be > sure that there is a valid policy data structure where we can read the > information from. Actually there is a way around that. - Revert one of my patches: commit f9f41e3ef99a ("cpufreq: Remove policy create/remove notifiers") - Use those notifiers in init_cpu_capacity_callback() instead of CPUFREQ_NOTIFY and set/reset a local policy pointer. - And this pointer we can use safely/reliably in topology_get_freq_scale(). We may need to use RCU read side protection in topology_get_freq_scale() though, to make sure the local policy pointer isn't getting updated simultaneously. - If the policy pointer isn't set, then we can use SCHED_CAPACITY_SCALE value instead. > Isn't the policy protected by a lock as well? There are locks, but you don't need any to read policy->cur. > Another thing is that I don't think a transition notifier based solution > or any other solution based on the cur/max ratio is really the right way > to go for fast-switching platforms. If we can do very frequent frequency > switching it makes less sense to use the current ratio whenever we > update the PELT averages as the frequency might have changed multiple > times since the last update. So it would make more sense to have an > average ratio instead. > If the platform has HW counters (e.g. APERF/MPERF) that can provide the > ratio then we should of course use those, if not, one solution could be > to let cpufreq track the average frequency for each cpu over a suitable > time window (around one sched period I think). It should be fairly low > overhead to maintain. In the topology driver, we would then choose > whether the scaling factor is provided by the cpufreq average frequency > ratio or the current transition notifier based approach based on the > capabilities of the platform. Hmm, maybe. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: viresh.kumar@linaro.org (Viresh Kumar) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support Date: Thu, 22 Jun 2017 09:36:43 +0530 [thread overview] Message-ID: <20170622040643.GB6314@vireshk-i7> (raw) In-Reply-To: <20170621165714.GB2551@e105550-lin.cambridge.arm.com> On 21-06-17, 17:57, Morten Rasmussen wrote: > It is true that this patch relies on the notifiers, but I don't see how > that prevents us from adding a non-notifier based solution for > fast-switch enabled platforms later? No it doesn't, but I thought it would be better to have a single solution (if possible) for all the cases here. > > I think this patch doesn't really need to go down the notifiers way. > > > > We can do something like this in the implementation of > > topology_get_freq_scale(): > > > > return (policy->cur << SCHED_CAPACITY_SHIFT) / max; > > > > Though, we would be required to take care of policy structure in this > > case somehow. > > This is exactly what this patch implements. Unfortunately we can't be > sure that there is a valid policy data structure where we can read the > information from. Actually there is a way around that. - Revert one of my patches: commit f9f41e3ef99a ("cpufreq: Remove policy create/remove notifiers") - Use those notifiers in init_cpu_capacity_callback() instead of CPUFREQ_NOTIFY and set/reset a local policy pointer. - And this pointer we can use safely/reliably in topology_get_freq_scale(). We may need to use RCU read side protection in topology_get_freq_scale() though, to make sure the local policy pointer isn't getting updated simultaneously. - If the policy pointer isn't set, then we can use SCHED_CAPACITY_SCALE value instead. > Isn't the policy protected by a lock as well? There are locks, but you don't need any to read policy->cur. > Another thing is that I don't think a transition notifier based solution > or any other solution based on the cur/max ratio is really the right way > to go for fast-switching platforms. If we can do very frequent frequency > switching it makes less sense to use the current ratio whenever we > update the PELT averages as the frequency might have changed multiple > times since the last update. So it would make more sense to have an > average ratio instead. > If the platform has HW counters (e.g. APERF/MPERF) that can provide the > ratio then we should of course use those, if not, one solution could be > to let cpufreq track the average frequency for each cpu over a suitable > time window (around one sched period I think). It should be fairly low > overhead to maintain. In the topology driver, we would then choose > whether the scaling factor is provided by the cpufreq average frequency > ratio or the current transition notifier based approach based on the > capabilities of the platform. Hmm, maybe. -- viresh
next prev parent reply other threads:[~2017-06-22 4:06 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-08 7:55 [PATCH 0/6] arm, arm64: frequency- and cpu-invariant accounting support for task scheduler Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-08 7:55 ` [PATCH 1/6] drivers base/arch_topology: prepare cpufreq policy notifier for frequency-invariant load-tracking support Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-12 14:45 ` Vincent Guittot 2017-06-12 14:45 ` Vincent Guittot 2017-06-08 7:55 ` [PATCH 2/6] drivers base/arch_topology: " Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-12 14:27 ` Vincent Guittot 2017-06-12 14:27 ` Vincent Guittot 2017-06-14 7:55 ` Dietmar Eggemann 2017-06-14 7:55 ` Dietmar Eggemann 2017-06-14 7:55 ` Dietmar Eggemann 2017-06-14 13:08 ` Vincent Guittot 2017-06-14 13:08 ` Vincent Guittot 2017-06-15 8:28 ` Juri Lelli 2017-06-15 8:28 ` Juri Lelli 2017-06-21 16:40 ` Dietmar Eggemann 2017-06-21 16:40 ` Dietmar Eggemann 2017-06-20 6:17 ` Viresh Kumar 2017-06-20 6:17 ` Viresh Kumar 2017-06-20 6:17 ` Viresh Kumar 2017-06-21 0:31 ` Saravana Kannan 2017-06-21 0:31 ` Saravana Kannan 2017-06-21 0:31 ` Saravana Kannan 2017-06-21 5:37 ` Viresh Kumar 2017-06-21 5:37 ` Viresh Kumar 2017-06-21 5:37 ` Viresh Kumar 2017-06-21 16:57 ` Morten Rasmussen 2017-06-21 16:57 ` Morten Rasmussen 2017-06-21 16:57 ` Morten Rasmussen 2017-06-22 4:06 ` Viresh Kumar [this message] 2017-06-22 4:06 ` Viresh Kumar 2017-06-22 4:06 ` Viresh Kumar 2017-06-22 9:59 ` Morten Rasmussen 2017-06-22 9:59 ` Morten Rasmussen 2017-06-22 9:59 ` Morten Rasmussen 2017-06-21 17:08 ` Dietmar Eggemann 2017-06-21 17:08 ` Dietmar Eggemann 2017-06-21 17:08 ` Dietmar Eggemann 2017-06-21 16:38 ` Dietmar Eggemann 2017-06-21 16:38 ` Dietmar Eggemann 2017-06-21 16:38 ` Dietmar Eggemann 2017-06-22 3:55 ` Viresh Kumar 2017-06-22 3:55 ` Viresh Kumar 2017-06-22 3:55 ` Viresh Kumar 2017-06-26 8:28 ` Dietmar Eggemann 2017-06-26 8:28 ` Dietmar Eggemann 2017-06-08 7:55 ` [PATCH 3/6] arm: wire frequency-invariant accounting support up to the task scheduler Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-12 14:30 ` Vincent Guittot 2017-06-12 14:30 ` Vincent Guittot 2017-06-08 7:55 ` [PATCH 4/6] arm: wire cpu-invariant " Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-12 14:31 ` Vincent Guittot 2017-06-12 14:31 ` Vincent Guittot 2017-06-08 7:55 ` [PATCH 5/6] arm64: wire frequency-invariant " Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-12 13:06 ` Catalin Marinas 2017-06-12 13:06 ` Catalin Marinas 2017-06-12 14:32 ` Vincent Guittot 2017-06-12 14:32 ` Vincent Guittot 2017-06-08 7:55 ` [PATCH 6/6] arm64: wire cpu-invariant " Dietmar Eggemann 2017-06-08 7:55 ` Dietmar Eggemann 2017-06-12 13:07 ` Catalin Marinas 2017-06-12 13:07 ` Catalin Marinas 2017-06-12 14:33 ` Vincent Guittot 2017-06-12 14:33 ` Vincent Guittot 2017-06-12 13:00 ` [PATCH 0/6] arm, arm64: frequency- and cpu-invariant accounting support for " Juri Lelli 2017-06-12 13:00 ` Juri Lelli 2017-06-12 13:04 ` Juri Lelli 2017-06-12 13:04 ` Juri Lelli
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=20170622040643.GB6314@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=dietmar.eggemann@arm.com \ --cc=gregkh@linuxfoundation.org \ --cc=juri.lelli@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=morten.rasmussen@arm.com \ --cc=peterz@infradead.org \ --cc=rmk+kernel@armlinux.org.uk \ --cc=skannan@codeaurora.org \ --cc=vincent.guittot@linaro.org \ --cc=will.deacon@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.