Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 05 Oct 2020 14:19:10 +0000
To:     "Limonciello, Mario" <Mario.Limonciello@dell.com>
From:   =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= <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>
Reply-To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= <pobrn@protonmail.com>
Subject: RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Message-ID: <Mz2G7glm3yMTniKA6SHM011dDkTFF4_otICrMQfVLheopX8JMGSupPleyjyK8OY0tyUazu09nX7XhleBVdl4ozTCWXCPGyvV58Qc-UUTvig=@protonmail.com>
In-Reply-To: <DM6PR19MB263669227D122BB7699951E6FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
References: <20201003131938.9426-1-hdegoede@redhat.com> <20201003131938.9426-2-hdegoede@redhat.com> <DM6PR19MB263669227D122BB7699951E6FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi


2020. okt=C3=B3ber 5., h=C3=A9tf=C5=91 14:58 keltez=C3=A9ssel, Limonciello,=
 Mario =C3=ADrta:
> > On modern systems CPU/GPU/... performance is often dynamically configur=
able
> > in the form of e.g. variable clock-speeds and TPD. The performance is o=
ften
> > automatically adjusted to the load by some automatic-mechanism (which m=
ay
> > very well live outside the kernel).
> > These auto performance-adjustment mechanisms often can be configured wi=
th
> > one of several performance-profiles, with either a bias towards low-pow=
er
> > consumption (and cool and quiet) or towards performance (and higher pow=
er
> > consumption and thermals).
> > Introduce a new performance_profile class/sysfs API which offers a gene=
ric
> > API for selecting the performance-profile of these automatic-mechanisms=
.
>
> If introducing an API for this - let me ask the question, why even let ea=
ch
> 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 notifi=
ed
> 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 we=
ll.
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? W=
hat if
the users wants to put one GPU into "low-power" mode, but the other one int=
o
"performance"? With the current specification, the user's needs could be ea=
sily
satisfied. I don't see how that's possible with a single switch. Nonetheles=
s, I think
that a single global switch *in addition* to the class devices could possib=
ly
simplify the userspace-kernel interaction for most users.


> 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 tie=
d 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=
?


> [...]


Thanks,
Barnab=C3=A1s P=C5=91cze