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