From: "Limonciello, Mario" <Mario.Limonciello@dell.com>
To: "Barnabás Pőcze" <pobrn@protonmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
Darren Hart <dvhart@infradead.org>,
Andy Shevchenko <andy@infradead.org>,
Mark Gross <mgross@linux.intel.com>,
Mark Pearson <mpearson@lenovo.com>,
Elia Devito <eliadevito@gmail.com>,
Bastien Nocera <hadess@hadess.net>,
Benjamin Berg <bberg@redhat.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mark Pearson <markpearson@lenovo.com>
Subject: RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Date: Mon, 5 Oct 2020 16:11:08 +0000 [thread overview]
Message-ID: <DM6PR19MB26369E7468931E63B69A0604FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com> (raw)
In-Reply-To: <Mz2G7glm3yMTniKA6SHM011dDkTFF4_otICrMQfVLheopX8JMGSupPleyjyK8OY0tyUazu09nX7XhleBVdl4ozTCWXCPGyvV58Qc-UUTvig=@protonmail.com>
> 2020. október 5., hétfő 14:58 keltezéssel, Limonciello, Mario írta:
> > > On modern systems CPU/GPU/... performance is often dynamically
> configurable
> > > in the form of e.g. variable clock-speeds and TPD. The performance is
> often
> > > automatically adjusted to the load by some automatic-mechanism (which may
> > > very well live outside the kernel).
> > > These auto performance-adjustment mechanisms often can be configured with
> > > one of several performance-profiles, with either a bias towards low-power
> > > consumption (and cool and quiet) or towards performance (and higher power
> > > consumption and thermals).
> > > Introduce a new performance_profile class/sysfs API which offers a generic
> > > API for selecting the performance-profile of these automatic-mechanisms.
> >
> > If introducing an API for this - let me ask the question, why even let each
> > driver offer a class interface and userspace need to change "each" driver's
> > performance setting?
> >
> > I would think that you could just offer something kernel-wide like
> > /sys/power/performance-profile
> >
> > Userspace can read and write to a single file. All drivers can get notified
> > on this sysfs file changing.
> >
>
> That makes sense, in my opinion, from the regular user's perspective:
> one switch to rule them all, no fuss. However, I don't think that scales well.
> What if the hypothetical users wants to run a CPU-heavy workload, and thus
> wants
> to put the GPU into "low-power" mode and the CPU into "performance" mode? What
> if
> the users wants to put one GPU into "low-power" mode, but the other one into
> "performance"? With the current specification, the user's needs could be
> easily
> satisfied. I don't see how that's possible with a single switch. Nonetheless,
> I think
> that a single global switch *in addition* to the class devices could possibly
> simplify the userspace-kernel interaction for most users.
I think that the moment you represent a platform/system device as a switch you
lose the ability to set different policies for other types of devices separately.
What if using the platform/system device actually /also/ orchestrates changes to
those other devices you mention? Then it becomes an order of events problem, or
worse a problem where one switch shows "wrong" value.
>
>
> > The systems that react in firmware (such as the two that prompted
> > this discussion) can change at that time. It leaves the possibility for a
> > more open kernel implementation that can do the same thing though too by
> > directly modifying device registers instead of ACPI devices.
> >
>
> Excuse my ignorance, but I don't really see why this interface would be tied
> to
> ACPI devices? Why is it not possible to write a driver that implements this
> interface
> and directly modifies device registers? Am I missing something obvious here?
>
When implemented for the two vendors mentioned here, it would be using a
proprietary "firmware API" implemented by those two vendors. For example write
arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to coordinate
using undisclosed protocol to affect the platform changes desirable.
This is different in my mind from "kernel writes to a specific register" to set
power properties of a specific device.
next prev parent reply other threads:[~2020-10-05 16:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-03 13:19 [RFC 0/1] Documentation: Add documentation for new performance_profile sysfs class Hans de Goede
2020-10-03 13:19 ` [RFC] " Hans de Goede
2020-10-04 1:33 ` [External] " Mark Pearson
2020-10-04 22:29 ` Elia Devito
2020-10-09 10:52 ` Hans de Goede
2020-10-05 12:58 ` Limonciello, Mario
2020-10-05 14:19 ` Barnabás Pőcze
2020-10-05 16:11 ` Limonciello, Mario [this message]
2020-10-05 16:47 ` [External] " Mark Pearson
2020-10-05 16:56 ` Limonciello, Mario
2020-10-05 17:46 ` Mark Pearson
2020-10-07 11:51 ` Bastien Nocera
2020-10-07 15:58 ` Limonciello, Mario
2020-10-07 16:34 ` Bastien Nocera
2020-10-07 18:41 ` Limonciello, Mario
2020-10-12 16:42 ` Rafael J. Wysocki
2020-10-13 13:09 ` Hans de Goede
2020-10-14 13:55 ` Rafael J. Wysocki
2020-10-14 14:16 ` Hans de Goede
2020-10-14 15:46 ` Rafael J. Wysocki
2020-10-14 17:44 ` Elia Devito
2020-10-14 18:11 ` Limonciello, Mario
2020-10-09 11:33 ` Hans de Goede
2020-10-05 13:13 ` Benjamin Berg
2020-10-09 11:15 ` Hans de Goede
2020-10-03 13:39 ` [RFC 0/1] " Hans de Goede
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=DM6PR19MB26369E7468931E63B69A0604FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com \
--to=mario.limonciello@dell.com \
--cc=andy@infradead.org \
--cc=bberg@redhat.com \
--cc=dvhart@infradead.org \
--cc=eliadevito@gmail.com \
--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=markpearson@lenovo.com \
--cc=mgross@linux.intel.com \
--cc=mpearson@lenovo.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=pobrn@protonmail.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).