Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp549881ima; Fri, 15 Mar 2019 08:37:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqzzWN6M7LhfSn6wBkcaABSNDvSN8YlLqI1i0Me1mCSkQwCk4RYHhqGHtgagaU44IKZO+sb/ X-Received: by 2002:a63:f80f:: with SMTP id n15mr4015853pgh.283.1552664270883; Fri, 15 Mar 2019 08:37:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552664270; cv=none; d=google.com; s=arc-20160816; b=H0PnH0X67Ij7I60PWidgItYQptoXcZZL+EuXiuf0o7DvNPoXI0TZ0YYPUN6k6MQX4Y r/pYPg3q2Z5dIFCzHmQL51Fd9dbXjAyegETXYYc+08j/3ow3z0isjcPTb0gcMNiCJFWB lP4SxPvI8rM/eBtJKdVaV9uiJopGnnfidFvq3B5LK/AEojZq2wPWn7YfOgBvVHUri79d yQhASUvywo2dKzo8tYsa5qsdxHoXEtQjH/nQBfBmP3v5BEJpTXTbfkmib9mmNoQLR4oy 2QJyrxv5Lo8f23Kb/N/Oh5dYaVX8xdczbaGd67D9xpgBUL/AC9K1o4BurXSGeFBsHflA WvMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=6iB/DnnXJ/J/2SZAqe9qkdUzvl0lXrdCzL/rmNV8rZQ=; b=Uv3hubAcdlAebRKc1fps3Sbeti3YT6h+E49ihXYTU8Xj7T7UgR0h6OgRTKV7tEaxWi /T4KHlVHbv80Wt2hImIYbjDj23ZQcNb23uqybtKGr4D1Tcr6pB9Gf+0Aip42rs0LU8ks wp1/Cxh8X78PoJhAEULj9WLavIxAiqS1UC++dud0trmyvBdbpvugNSQcM90WAPm63lF4 z3MstcsZ2QYi77OEq52LHSUTRBOkQi9x2BQQEhc2yQzaua9IUoU9V38JZU5mTgU9heMp 3ZG6sovBtrjEZ2brl0Q5NZXw1gtrBOeI2VQ4eJZyp4CtCpHVEbnhxECHe7GQ23knXN0a VfNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o32si2145306pld.46.2019.03.15.08.37.33; Fri, 15 Mar 2019 08:37:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729314AbfCOPg4 (ORCPT + 99 others); Fri, 15 Mar 2019 11:36:56 -0400 Received: from mx2.suse.de ([195.135.220.15]:36124 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726792AbfCOPg4 (ORCPT ); Fri, 15 Mar 2019 11:36:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D88DDAC44; Fri, 15 Mar 2019 15:36:53 +0000 (UTC) From: Thomas Renninger To: "Rafael J. Wysocki" Cc: Len Brown , Hannes Reinecke , Linux PM , LKML , Borislav Petkov , Simon Schricker , Srinivas Pandruvada , Len Brown Subject: Re: [PATCH] [RESEND] Do not modify perf bias performance setting by default at boot Date: Fri, 15 Mar 2019 16:36:53 +0100 Message-ID: <2947538.dvgdW3vLlg@house> In-Reply-To: References: <6369897.qxlu8PgE1t@house> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rafael, On Thursday, March 14, 2019 11:08:03 PM CET Rafael J. Wysocki wrote: > On Thu, Mar 14, 2019 at 3:42 PM Thomas Renninger wrote: > > This is a revert of mainline git commits: > > commit b51ef52df71cb28e9d90cd1d48b79bf19f0bab06 > > commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 > > commit abe48b108247e9b90b4c6739662a2e5c765ed114 > > I'm not quite convinced that reverting these is the right thing to do here. Ok, I try harder. > > It is about this kernel message showing up on quite a lot servers: > > [ 0.072652] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' > > [ 0.076003] ENERGY_PERF_BIAS: View and update with > > x86_energy_perf_policy(8) > What happens on boot is a matter of convention and the convention by > which the EPB is set to "neutral" at that point has been used for > quite a while. Changing it now may confuse some users or even worse. SUSE has this patch included for quite a while (in all kind of SLE 12 SP flavors), possibly other distributions as well. Unfortunately the patch got removed recently, because my commit (this one) was ignored by Len a while ago. I also like to see more examples of BIOSes not initializing this value. This message is rare (so the setting back does not happen often, probably only wrongly with latest BIOSes overriding intended BIOS performance settings on servers). On my workstation the BIOS initializes perf bias to: cpupower info analyzing CPU 0: perf-bias: 7 I could grep through quite some dozens of machines..., but these are mostly servers and probably show either "zero"/"performance" or "6"/"normal" because the Linux kernel overrides the INTENDED performance perf bias value to 6. So we (SUSE) are going with this patch forever. Otherwise we would run into a similar support nightmare we ran into, when Intel decided to ignore CPU idle states as exported by BIOS through ACPI. BIOS documentation of all big server vendors mentioned "performance" settings. With a kernel update these BIOS C states settings have been ignored (some long latency once were not exported on purpose). The list of breaking conventions and specifications is long... People mostly blame the "bad BIOS developer". In this case things have been broke by the kernel. It's now (with the resume patch) broken in way, that "performance" setting in the mainline kernel is unusable for years already. Can we please get this finally properly fixed! > That is a bug. There is no reason to change the EPB on CPU > offline/online and I agree that this needs to be fixed. The reverts > would make this problem go away, but that's not the only possible way > to fix it. It is the only proper way to fix this. > Moreover, what is done during system-wide resume appears to be a bug > too. Whatever EPB value is there during suspend should be saved and > it should be restored during resume. Reverting the commits above will > not fix that particular issue. Someone could have a look what happens on a recent system after suspend (with this patch on top). I do not have laptops to test suspend/resume with latest kernels. These broken patches have been added a bit too quickly. I doubt much BIOSes "forgot to initialize this value" and I have my doubts that resume let's the CPU fall back to "uninitialized" value. I more expect BIOS resets performance value after resume and the kernel is doing it all wrong. Hm, in fact this could be proofed by modifying perf bias value, do a suspend resume cyle. If the value is kept we should avoid another try of complicating things and simply reverting touching perf bias value altogether, correct? BIOS probably does not store perf BIAS value and re-applies it after suspend resume. Some might re-set it to the intial value (performance..., D'oh). Thomas