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]

Message-ID: <DM6PR19MB26364E6AA2F51981F592CE58FA0A0@DM6PR19MB2636.namprd19.prod.outlook.com>
Date:   Wed, 7 Oct 2020 15:58:52 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@...l.com>
To:     Bastien Nocera <hadess@...ess.net>,
        Hans de Goede <hdegoede@...hat.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Mark Gross <mgross@...ux.intel.com>
CC:     Mark Pearson <mpearson@...ovo.com>,
        Elia Devito <eliadevito@...il.com>,
        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

 
> On Mon, 2020-10-05 at 12:58 +0000, Limonciello, Mario wrote:
> > > 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.
> >
> > 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.
> 
> The problem, as I've mentioned in previous discussions we had about
> this, is that, as you've seen in replies to this mail, this would
> suddenly be making the kernel apply policy.
> 
> There's going to be pushback as soon as policy is enacted in the
> kernel, and you take away the different knobs for individual components
> (or you can control them centrally as well as individually). As much as
> I hate the quantity of knobs[1], I don't think that trying to reduce
> the number of knobs in the kernel is a good use of our time, and easier
> to enact, coordinated with design targets, in user-space.
> 
> Unless you can think of a way to implement this kernel wide setting
> without adding one more exponent on the number of possibilities for the
> testing matrix, I'll +1 Hans' original API.
> 
Actually I offered two proposals in my reply.  So are you NAKing both?
The other one suggested to use the same firmware attributes class being
introduced by the new Dell driver (https://patchwork.kernel.org/patch/11818343/)
since this is actually a knob to a specific firmware setting.