lkml.org 
[lkml]   [2020]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Date

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

\
 
 \ /
  Last update: 2020-10-07 17:59    [W:0.133 / U:0.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site