From: Lukasz Luba <lukasz.luba@arm.com> To: Sudeep Holla <sudeep.holla@arm.com>, Viresh Kumar <viresh.kumar@linaro.org> Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org, cristian.marussi@arm.com, rjw@rjwysocki.net Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers Date: Thu, 30 Jul 2020 10:36:51 +0100 [thread overview] Message-ID: <3b3a56e9-29ec-958f-fb3b-c689a9389d2f@arm.com> (raw) In-Reply-To: <20200730091014.GA13158@bogus> On 7/30/20 10:10 AM, Sudeep Holla wrote: > On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: >> On 29-07-20, 16:12, Lukasz Luba wrote: >>> The existing CPUFreq framework does not tracks the statistics when the >>> 'fast switch' is used or when firmware changes the frequency independently >>> due to e.g. thermal reasons. However, the firmware might track the frequency >>> changes and expose this to the kernel. >>> >>> This patch set aims to introduce CPUfreq statistics gathered by firmware >>> and retrieved by CPUFreq driver. It would require a new API functions >>> in the CPUFreq, which allows to poke drivers to get these stats. >>> >>> The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends >>> ARM SCMI protocol layer, patches 3/4, 4/4 modify ARM SCMI CPUFreq driver. >> >> Are you doing this for the fast switch case or because your platform >> actually runs at frequencies which may be different from what cpufreq >> core has requested ? >> > > I think so. For both cases, but fast switch is major and present. Thermal is not currently implemented in SCP FW, but might be in future. > >> I am also not sure what these tables should represent, what the >> cpufreq core has decided for the CPUs or the frequencies we actually >> run at, as these two can be very different for example if the hardware >> runs at frequencies which don't match exactly to what is there in the >> freq table. I believe these are rather to show what cpufreq and its >> governors are doing with the CPUs. >> > > Exactly, I raised similar point in internal discussion and asked Lukasz > to take up the same on the list. I assume it was always what cpufreq > requested rather than what was delivered. So will we break the userspace > ABI if we change that is the main question. Thank you for confirmation. If that is the mechanism for tracking what cpufreq governors are doing with the CPUs, then is clashes with presented data in FW memory, because firmware is the governor. > >> Over that I would like the userspace stats to work exactly as the way >> they work right now, i.e. capture all transitions from one freq to >> other, not just time-in-state. Also resetting of the stats from >> userspace for example. All allocation and printing of the data must be >> done from stats core, the only thing which the driver would do at the >> end is updating the stats structure and nothing more. Instead of >> reading all stats from the firmware, it will be much easier if you can >> just get the information from the firmware whenever there is a >> frequency switch and then we can update the stats the way it is done >> right now. And that would be simple. >> > > Good point, but notifications may not be lightweight. If that is no good, > alternatively, I suggested to keep these firmware stats in a separate > debugfs. Thoughts ? I agree that notifications might not be lightweight. Furthermore I think this still clashes with the assumption that cpufreq governor decisions are tracked in these statistics, not the firmware decision. In this case I think we would have to create debugfs. Sudeep do you think these debugfs should be exposed from the protocol layer: drivers/firmware/arm_scmi/perf.c or maybe from the cpufreq scmi driver? I would probably be safer to have it in the cpufreq driver because we have scmi_handle there. Regards, Lukasz
WARNING: multiple messages have this Message-ID (diff)
From: Lukasz Luba <lukasz.luba@arm.com> To: Sudeep Holla <sudeep.holla@arm.com>, Viresh Kumar <viresh.kumar@linaro.org> Cc: rjw@rjwysocki.net, cristian.marussi@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org Subject: Re: [PATCH 0/4] CPUFreq statistics retrieved by drivers Date: Thu, 30 Jul 2020 10:36:51 +0100 [thread overview] Message-ID: <3b3a56e9-29ec-958f-fb3b-c689a9389d2f@arm.com> (raw) In-Reply-To: <20200730091014.GA13158@bogus> On 7/30/20 10:10 AM, Sudeep Holla wrote: > On Thu, Jul 30, 2020 at 02:23:33PM +0530, Viresh Kumar wrote: >> On 29-07-20, 16:12, Lukasz Luba wrote: >>> The existing CPUFreq framework does not tracks the statistics when the >>> 'fast switch' is used or when firmware changes the frequency independently >>> due to e.g. thermal reasons. However, the firmware might track the frequency >>> changes and expose this to the kernel. >>> >>> This patch set aims to introduce CPUfreq statistics gathered by firmware >>> and retrieved by CPUFreq driver. It would require a new API functions >>> in the CPUFreq, which allows to poke drivers to get these stats. >>> >>> The needed CPUFreq infrastructure is in patch 1/4, patch 2/4 extends >>> ARM SCMI protocol layer, patches 3/4, 4/4 modify ARM SCMI CPUFreq driver. >> >> Are you doing this for the fast switch case or because your platform >> actually runs at frequencies which may be different from what cpufreq >> core has requested ? >> > > I think so. For both cases, but fast switch is major and present. Thermal is not currently implemented in SCP FW, but might be in future. > >> I am also not sure what these tables should represent, what the >> cpufreq core has decided for the CPUs or the frequencies we actually >> run at, as these two can be very different for example if the hardware >> runs at frequencies which don't match exactly to what is there in the >> freq table. I believe these are rather to show what cpufreq and its >> governors are doing with the CPUs. >> > > Exactly, I raised similar point in internal discussion and asked Lukasz > to take up the same on the list. I assume it was always what cpufreq > requested rather than what was delivered. So will we break the userspace > ABI if we change that is the main question. Thank you for confirmation. If that is the mechanism for tracking what cpufreq governors are doing with the CPUs, then is clashes with presented data in FW memory, because firmware is the governor. > >> Over that I would like the userspace stats to work exactly as the way >> they work right now, i.e. capture all transitions from one freq to >> other, not just time-in-state. Also resetting of the stats from >> userspace for example. All allocation and printing of the data must be >> done from stats core, the only thing which the driver would do at the >> end is updating the stats structure and nothing more. Instead of >> reading all stats from the firmware, it will be much easier if you can >> just get the information from the firmware whenever there is a >> frequency switch and then we can update the stats the way it is done >> right now. And that would be simple. >> > > Good point, but notifications may not be lightweight. If that is no good, > alternatively, I suggested to keep these firmware stats in a separate > debugfs. Thoughts ? I agree that notifications might not be lightweight. Furthermore I think this still clashes with the assumption that cpufreq governor decisions are tracked in these statistics, not the firmware decision. In this case I think we would have to create debugfs. Sudeep do you think these debugfs should be exposed from the protocol layer: drivers/firmware/arm_scmi/perf.c or maybe from the cpufreq scmi driver? I would probably be safer to have it in the cpufreq driver because we have scmi_handle there. Regards, Lukasz _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-30 9:36 UTC|newest] Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-29 15:12 [PATCH 0/4] CPUFreq statistics retrieved by drivers Lukasz Luba 2020-07-29 15:12 ` Lukasz Luba 2020-07-29 15:12 ` [PATCH 1/4] cpufreq: Add support for statistics read from drivers Lukasz Luba 2020-07-29 15:12 ` Lukasz Luba 2020-07-29 15:12 ` [PATCH 2/4] scmi: perf: Extend protocol to support performance statistics Lukasz Luba 2020-07-29 15:12 ` Lukasz Luba 2020-07-31 1:50 ` kernel test robot 2020-07-31 1:50 ` kernel test robot 2020-07-31 1:50 ` kernel test robot 2020-07-31 15:15 ` Cristian Marussi 2020-07-31 15:15 ` Cristian Marussi 2020-08-04 11:10 ` Lukasz Luba 2020-08-04 11:10 ` Lukasz Luba 2020-07-29 15:12 ` [PATCH 3/4] cpufreq: scmi: Move scmi_cpufreq_driver structure to the top Lukasz Luba 2020-07-29 15:12 ` Lukasz Luba 2020-07-29 15:12 ` [PATCH 4/4] cpufreq: scmi: Read statistics from FW shared memory Lukasz Luba 2020-07-29 15:12 ` Lukasz Luba 2020-07-30 8:53 ` [PATCH 0/4] CPUFreq statistics retrieved by drivers Viresh Kumar 2020-07-30 8:53 ` Viresh Kumar 2020-07-30 9:10 ` Sudeep Holla 2020-07-30 9:10 ` Sudeep Holla 2020-07-30 9:36 ` Lukasz Luba [this message] 2020-07-30 9:36 ` Lukasz Luba 2020-07-31 15:56 ` Sudeep Holla 2020-07-31 15:56 ` Sudeep Holla 2020-08-04 17:19 ` Florian Fainelli 2020-08-04 17:19 ` Florian Fainelli 2020-08-05 12:36 ` Sudeep Holla 2020-08-05 12:36 ` Sudeep Holla 2020-08-04 5:35 ` Viresh Kumar 2020-08-04 5:35 ` Viresh Kumar 2020-08-04 10:29 ` Lukasz Luba 2020-08-04 10:29 ` Lukasz Luba 2020-08-04 10:38 ` Viresh Kumar 2020-08-04 10:38 ` Viresh Kumar 2020-08-04 10:44 ` Lukasz Luba 2020-08-04 10:44 ` Lukasz Luba 2020-09-02 7:26 ` Viresh Kumar 2020-09-02 7:26 ` Viresh Kumar 2020-08-04 17:27 ` Florian Fainelli 2020-08-04 17:27 ` Florian Fainelli 2020-08-05 11:04 ` Lukasz Luba 2020-08-05 11:04 ` Lukasz Luba 2020-08-05 13:04 ` Viresh Kumar 2020-08-05 13:04 ` Viresh Kumar 2020-08-05 16:03 ` Sudeep Holla 2020-08-05 16:03 ` Sudeep Holla 2020-08-05 17:33 ` Florian Fainelli 2020-08-05 17:33 ` Florian Fainelli 2020-08-06 13:37 ` Sudeep Holla 2020-08-06 13:37 ` Sudeep Holla
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=3b3a56e9-29ec-958f-fb3b-c689a9389d2f@arm.com \ --to=lukasz.luba@arm.com \ --cc=cristian.marussi@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=rjw@rjwysocki.net \ --cc=sudeep.holla@arm.com \ --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.