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]
Message-ID: <DM6PR19MB26369E7468931E63B69A0604FA0C0@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Mon, 5 Oct 2020 16:11:08 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     Barnabás Pőcze <pobrn@...tonmail.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

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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ