From: Elia Devito <eliadevito@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Hans de Goede <hdegoede@redhat.com>,
Mark Pearson <markpearson@lenovo.com>
Cc: aniel Lezcano <daniel.lezcano@linaro.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Lukasz Luba <lukasz.luba@arm.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
"Zhang, Rui" <rui.zhang@intel.com>,
Bastien Nocera <hadess@hadess.net>,
"Limonciello, Mario" <Mario.Limonciello@dell.com>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Mark Gross <mgross@linux.intel.com>,
Benjamin Berg <bberg@redhat.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>
Subject: Re: Fw: [External] Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Date: Fri, 16 Oct 2020 17:16:46 +0200 [thread overview]
Message-ID: <5679624.lOV4Wx5bFT@pce> (raw)
In-Reply-To: <f9163f54-9379-89f6-aaaf-e2d5084051df@lenovo.com>
Hi,
In data venerdì 16 ottobre 2020 16:43:09 CEST, Mark Pearson ha scritto:
> <Note - switched my email address to my more open source non-outlook
> based address>
>
> On 2020-10-16 10:32 a.m., Mark Pearson wrote:
> > ------------------------------------------------------------------------
> > *From:* Elia Devito <eliadevito@gmail.com>
> > *Sent:* October 16, 2020 10:26
> > *To:* Rafael J. Wysocki <rafael@kernel.org>; Hans de Goede
> > <hdegoede@redhat.com>
> > *Cc:* Daniel Lezcano <daniel.lezcano@linaro.org>; Srinivas Pandruvada
> > <srinivas.pandruvada@linux.intel.com>; Lukasz Luba
> > <lukasz.luba@arm.com>; Linux Kernel Mailing List
> > <linux-kernel@vger.kernel.org>; Linux PM <linux-pm@vger.kernel.org>;
> > Zhang, Rui <rui.zhang@intel.com>; Bastien Nocera <hadess@hadess.net>;
> > Mark Pearson <mpearson@lenovo.com>; Limonciello, Mario
> > <Mario.Limonciello@dell.com>; Darren Hart <dvhart@infradead.org>; Andy
> > Shevchenko <andy@infradead.org>; Mark Gross <mgross@linux.intel.com>;
> > Benjamin Berg <bberg@redhat.com>; linux-acpi@vger.kernel.org
> > <linux-acpi@vger.kernel.org>; platform-driver-x86@vger.kernel.org
> > <platform-driver-x86@vger.kernel.org>
> > *Subject:* [External] Re: [RFC] Documentation: Add documentation for new
> > performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add
> > the DTPM framework)
> > Hi,
> >
> > In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto:
> >> <note folding the 2 threads we are having on this into one, adding every
> >> one from both threads to the Cc>
> >>
> >> Hi,
> >>
> >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote:
> >> > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede <hdegoede@redhat.com>
wrote:
> >> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote:
> >> <snip>
> >>
> >> >>> First, a common place to register a DPTF system profile seems to be
> >> >>> needed and, as I said above, I wouldn't expect more than one such
> >> >>> thing to be present in the system at any given time, so it may be
> >> >>> registered along with the list of supported profiles and user space
> >> >>> will have to understand what they mean.
> >> >>
> >> >> Mostly Ack, I would still like to have an enum for DPTF system
> >> >> profiles in the kernel and have a single piece of code map that
> >> >> enum to profile names. This enum can then be extended as
> >> >> necessary, but I want to avoid having one driver use
> >> >> "Performance" and the other "performance" or one using
> >> >> "performance-balanced" and the other "balanced-performance", etc.
> >> >>
> >> >> With the goal being that new drivers use existing values from
> >> >> the enum as much as possible, but we extend it where necessary.
> >> >
> >> > IOW, just a table of known profile names with specific indices assigned
> >> > to
> >> > them.
> >>
> >> Yes.
> >>
> >> > This sounds reasonable.
> >> >
> >> >>> Second, irrespective of the above, it may be useful to have a
> >> >>> consistent way to pass performance-vs-power preference information
> >> >>> from user space to different parts of the kernel so as to allow them
> >> >>> to adjust their operation and this could be done with a system-wide
> >> >>> power profile attribute IMO.
> >> >>
> >> >> I agree, which is why I tried to tackle both things in one go,
> >> >> but as you said doing both in 1 API is probably not the best idea.
> >> >> So I believe we should park this second issue for now and revisit it
> >> >> when we find a need for it.
> >> >
> >> > Agreed.
> >> >
> >> >> Do you have any specific userspace API in mind for the
> >> >> DPTF system profile selection?
> >> >
> >> > Not really.
> >>
> >> So before /sys/power/profile was mentioned, but that seems more like
> >> a thing which should have a set of fixed possible values, iow that is
> >> out of scope for this discussion.
> >>
> >> Since we all seem to agree that this is something which we need
> >> specifically for DPTF profiles maybe just add:
> >>
> >> /sys/power/dptf_current_profile (rw)
> >> /sys/power/dptf_available_profiles (ro)
> >>
> >> (which will only be visible if a dptf-profile handler
> >>
> >> has been registered) ?
> >>
> >> Or more generic and thus better (in case other platforms
> >> later need something similar) I think, mirror the:
> >>
> >> /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits
> >> for a system-wide energy-performance setting, so we get:
> >>
> >> /sys/power/energy_performance_preference
> >> /sys/power/energy_performance_available_preferences
> >>
> >> (again only visible when applicable) ?
> >>
> >> I personally like the second option best.
> >>
> >> Regards,
> >>
> >> Hans
> >
> > between the two, the second seems to me more appropriate.
> > Considering that the various profiles interact with thermal behaviors
> > what do
> > you think of something like:
> >
> > /sys/power/thermal_profile_available_profiles
> > /sys/power/thermal_profile_profile
> >
> > Regards,
> > Elia
>
> I'm good with either but I do find 'profile_profile' slightly awkward to
> say out loud (even though it's logically correct :))
>
> How about just:
> /sys/power/platform_profile
> /sys/power/platform_profile_available
>
> As it covers the platform as a whole - fans, temperature, power, and
> anything else that ends up getting thrown in?
>
> Mark
Completely agree, I made a typo xD
Elia
next prev parent reply other threads:[~2020-10-16 15:16 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 12:20 [PATCH 0/4] powercap/dtpm: Add the DTPM framework Daniel Lezcano
2020-10-06 12:20 ` [PATCH 1/4] units: Add Watt units Daniel Lezcano
2020-11-10 10:02 ` Lukasz Luba
2020-10-06 12:20 ` [PATCH 2/4] Documentation/powercap/dtpm: Add documentation for dtpm Daniel Lezcano
2020-10-13 22:01 ` Ram Chandrasekar
2020-10-06 12:20 ` [PATCH 3/4] powercap/drivers/dtpm: Add API for dynamic thermal power management Daniel Lezcano
2020-10-06 16:42 ` kernel test robot
2020-10-06 18:05 ` kernel test robot
2020-10-23 10:29 ` Lukasz Luba
2020-11-03 18:42 ` Daniel Lezcano
2020-11-10 9:59 ` Lukasz Luba
2020-11-10 11:05 ` Lukasz Luba
2020-11-10 14:59 ` Daniel Lezcano
2020-11-10 15:04 ` Lukasz Luba
2020-11-10 12:55 ` Daniel Lezcano
2020-10-06 12:20 ` [PATCH 4/4] powercap/drivers/dtpm: Add CPU energy model based support Daniel Lezcano
2020-10-23 13:27 ` Lukasz Luba
2020-11-04 10:47 ` Daniel Lezcano
2020-11-04 10:57 ` Lukasz Luba
2020-11-04 11:15 ` Daniel Lezcano
2020-11-10 12:50 ` Lukasz Luba
2020-10-07 10:43 ` [PATCH 0/4] powercap/dtpm: Add the DTPM framework Hans de Goede
2020-10-12 10:30 ` Daniel Lezcano
2020-10-12 11:46 ` Hans de Goede
2020-10-12 16:02 ` Daniel Lezcano
2020-10-13 12:47 ` Hans de Goede
2020-10-12 16:37 ` Rafael J. Wysocki
2020-10-13 13:04 ` Hans de Goede
2020-10-14 13:33 ` Rafael J. Wysocki
2020-10-14 14:06 ` Hans de Goede
2020-10-14 15:42 ` Rafael J. Wysocki
2020-10-16 11:10 ` [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework) Hans de Goede
2020-10-16 14:26 ` Elia Devito
[not found] ` <HK2PR0302MB2449214B28438ADC1790D468BD030@HK2PR0302MB2449.apcprd03.prod.outlook.com>
2020-10-16 14:43 ` Fw: [External] " Mark Pearson
2020-10-16 15:16 ` Elia Devito [this message]
2020-10-16 14:51 ` Rafael J. Wysocki
2020-10-18 9:41 ` Hans de Goede
2020-10-18 12:31 ` Rafael J. Wysocki
2020-10-19 18:43 ` Hans de Goede
[not found] ` <HK2PR0302MB24494037019FBC7720976735BD1E0@HK2PR0302MB2449.apcprd03.prod.outlook.com>
2020-10-19 18:49 ` Fw: [External] " Mark Pearson
2020-10-25 10:13 ` Hans de Goede
2020-10-20 12:34 ` Rafael J. Wysocki
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=5679624.lOV4Wx5bFT@pce \
--to=eliadevito@gmail.com \
--cc=Mario.Limonciello@dell.com \
--cc=andy@infradead.org \
--cc=bberg@redhat.com \
--cc=daniel.lezcano@linaro.org \
--cc=dvhart@infradead.org \
--cc=hadess@hadess.net \
--cc=hdegoede@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=markpearson@lenovo.com \
--cc=mgross@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).