Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
Date:   Tue, 05 Dec 2023 12:00:04 +0000
From:   David Woodhouse <dwmw2@infradead.org>
To:     pdurrant@amazon.co.uk
CC:     bp@alien8.de, dave.hansen@intel.com, dave.hansen@linux.intel.com,
        hdegoede@redhat.com, hpa@zytor.com, jalliste@amazon.co.uk,
        juew@amazon.com, len.brown@intel.com, linux-kernel@vger.kernel.org,
        mingo@redhat.com, peterz@infradead.org, rafael.j.wysocki@intel.com,
        rafael@kernel.org, tglx@linutronix.de, usama.arif@bytedance.com,
        x86@kernel.org
Subject: =?US-ASCII?Q?RE=3A_=5BPATCH=5D_x86=3A_intel=5Fepb=3A_Add_earlyp?= =?US-ASCII?Q?aram_option_to_keep_bias_at_performance?=
User-Agent: K-9 Mail for Android
In-Reply-To: <53bce76c5c60463eba1372df426a64b9@amazon.co.uk>
Message-ID: <1D71D218-5EB6-47DE-A01B-3A66F9F4C74E@infradead.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk


Paul writes:
> The problem is that this will take effect even on a kexec and hence it i=
s throttling
> a system that set ENERGY_PERF_BIAS_PERFORMANCE prior to the kexec=2E  We=
 use kexec to
> live update the host kernel of our systems whilst leaving virtual machin=
es running=2E
> This resetting of the perf bias is having a very detrimental effect on t=
he downtime
> of our systems across the live update - about a 7 fold increase=2E

It isn't just about kexec, is it? Even in a clean boot why wouldn't we wan=
t to stay in performance mode until the kernel has *finished* booting? It's=
 literally adding seconds to the startup time in some cases=2E

And yes, we *particularly* care in the kexec case because guests experienc=
e it as excessive steal time=2E But it ain't great in the general case eith=
er, surely?