linux-kernel - RE: [RFC] Documentation: Add documentation for new performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 05 Oct 2020 14:19:10 +0000
From:   Barnabás Pőcze <pobrn@...tonmail.com>
To:     "Limonciello, Mario" <Mario.Limonciello@...l.com>
Cc:     Hans de Goede <hdegoede@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Mark Gross <mgross@...ux.intel.com>,
        Mark Pearson <mpearson@...ovo.com>,
        Elia Devito <eliadevito@...il.com>,
        Bastien Nocera <hadess@...ess.net>,
        Benjamin Berg <bberg@...hat.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Pearson <markpearson@...ovo.com>
Subject: RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class

Hi


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.


> 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?


> [...]


Thanks,
Barnabás Pőcze