[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7070d14f-d35b-4b6a-9038-20dcbb984776@intel.com>
Date: Tue, 5 Dec 2023 07:19:44 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>,
David Woodhouse <dwmw2@...radead.org>
Cc: pdurrant@...zon.co.uk, bp@...en8.de, dave.hansen@...ux.intel.com,
hdegoede@...hat.com, hpa@...or.com, jalliste@...zon.co.uk,
juew@...zon.com, len.brown@...el.com, linux-kernel@...r.kernel.org,
mingo@...hat.com, peterz@...radead.org, rafael.j.wysocki@...el.com,
tglx@...utronix.de, usama.arif@...edance.com, x86@...nel.org
Subject: Re: [PATCH] x86: intel_epb: Add earlyparam option to keep bias at
performance
On 12/5/23 04:12, Rafael J. Wysocki wrote:
>> And yes, we *particularly* care in the kexec case because guests experience it as excessive steal time. But it ain't great in the general case either, surely?
> So IMV it would be perfectly fine to add a command line arg to provide
> the initial value of energy_perf_bias for the ones who know what they
> are doing.
Let's say we're on a system where the default is "normal" and the user
actually decides they want "performance"? Is that rational? Should the
command-line be more general in specifying a desired performance level
instead of just flipping the hack on and off?
We could, for instance just support this pair:
intel_epb=auto (default, will hack performance=>normal)
intel_epb=preserve (leave it alone)
for now. That would give us the existing behavior and the override that
folks want for kexec. But it would also leave open the possibility to
do things like this in the future:
intel_epb=normal (always override to normal)
intel_epb=performance (always override to performance)
Powered by blists - more mailing lists