Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1452502pxu; Thu, 8 Oct 2020 11:49:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzhw2XUMma78tTjy3hkIss7y9JZzeHMxIJdnDGw1TccZhXjUxtFA/fEl/dnOk3lqsefwQs X-Received: by 2002:a17:906:edb0:: with SMTP id sa16mr10077469ejb.327.1602182952038; Thu, 08 Oct 2020 11:49:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602182952; cv=none; d=google.com; s=arc-20160816; b=hImuO0397NryWaJFTNb4QSoYOijMVvziUb+RGcBq4wNIRZsI9SLnSygXjEh6UBLYq4 OEXjiNBtgKqtCxz0aVl2tCopfNU6BERFu8N2478UAsMv2JVzMoTeXbUaN1rY8wSA6Plh mIg7Y71GZM/WIV/BbsItBad9wXapmje/u2DJh3czb1gj0TyKGEuVnUXYqoRlkLXld5Lb JwX6nSc6q5j9+CGHB+90FPz8ZMucdUM0/ZjFzIpKvs0OjBEvPUjZ2jmplxI3RCOSou42 HXqfKRYEHs+U4EKqZnY5x8Qjaet8sNnNAN3SwHCXH1SxicKXa85jV4UNY9RFHP3VK86d BvWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ugzBDRm+nhb/g4Z1JHMKmZRZoARO+iEN3o8MGi7u60k=; b=tXEOnUF9GUzCnCYSegLDfPgeFj8oTOqP2sV8Mdgh6vdGT2Z9Pf+nsSSQQW8vsR8uH8 aghKtVyH8hHNRCaZwBiuLVVljsdYg+JdsrdtVsVShCV7q6cLj+za+UmWQqUwvXbTZqNw uhMVJ9LldNBVa5I0rGedCDlbCsX8O1zKEOv/2RlRZGc/IqkRbiZ8clAD5R7KB8D0Rggk Zx9n6AEnNuHJS81zoNQvdI5VOzr5lNnCwAbUG0zt85TQGWJUbq5C6qverxpJtXa5xCPz 5QeXQ8KknlKhHgAs6UtlEDAO4fL5gR2GN7JIAYG/VPv3CAna7QfJYXPEkYrRk7eFNR2Z 5dEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x23si4398901eju.401.2020.10.08.11.48.48; Thu, 08 Oct 2020 11:49:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732146AbgJHRek (ORCPT + 99 others); Thu, 8 Oct 2020 13:34:40 -0400 Received: from outbound-smtp44.blacknight.com ([46.22.136.52]:47097 "EHLO outbound-smtp44.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731283AbgJHRek (ORCPT ); Thu, 8 Oct 2020 13:34:40 -0400 Received: from mail.blacknight.com (pemlinmail05.blacknight.ie [81.17.254.26]) by outbound-smtp44.blacknight.com (Postfix) with ESMTPS id E4DF3F858E for ; Thu, 8 Oct 2020 18:34:37 +0100 (IST) Received: (qmail 21396 invoked from network); 8 Oct 2020 17:34:37 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 8 Oct 2020 17:34:37 -0000 Date: Thu, 8 Oct 2020 18:34:36 +0100 From: Mel Gorman To: "Rafael J. Wysocki" Cc: Takashi Iwai , linux-kernel@vger.kernel.org Subject: Re: ACPI _CST introduced performance regresions on Haswll Message-ID: <20201008173436.GQ3227@techsingularity.net> References: <20201006083639.GJ3227@techsingularity.net> <20201006190322.GL3227@techsingularity.net> <25f31d3e-7a67-935f-93ba-32216a5084e2@intel.com> <20201006211820.GN3227@techsingularity.net> <2382d796-7c2f-665e-9169-5cdc437bf34c@intel.com> <20201008090909.GP3227@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 08, 2020 at 07:15:46PM +0200, Rafael J. Wysocki wrote: > > Force enabling C6 > > > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state3/disable:1 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state4/disable:0 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state0/default_status:enabled > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state1/default_status:enabled > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state2/default_status:enabled > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state3/default_status:disabled > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state4/default_status:enabled > > > > Note that as expected, C3 remains disabled when only C6 is forced (state3 > > == c3, state4 == c6). While this particular workload does not appear to > > care as it does not remain idle for long, the exit latency difference > > between c3 and c6 is large so potentially a workload that idles for short > > durations that are somewhere between c1e and c3 exit latency might take > > a larger penalty exiting from c6 state if the deeper c-state is selected > > for idling. > > > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state0/residency:0 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state1/residency:2 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state2/residency:20 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state3/residency:100 > > ./5.9.0-rc8-enable-c6/iter-0/sys/devices/system/cpu/cpu0/cpuidle/state4/residency:400 > > > > If you are worried that C6 might be used instead of C3 in some cases, this > is not going to happen. > Ok, so it goes in the C1E direction instead. I lost track of how C-state is selected based on predictions about the future. It's changed a bit over time. > I all cases in which C3 would have been used had it not been disabled, C1E > will be used instead. > > Which BTW indicates that using C1E more often adds a lot of latency to the > workload (if C3 and C6 are both disabled, C1E is used in all cases in which > one of them would have been used). Which is weird. From the exit latency alone, I'd think it would be faster to use C1E instead of C3. It implies that using C1E instead of C3/C6 has some other side-effect on Haswell. At one point, there was plenty of advice on disabling C1E but very little concrete information on what impact it has exactly and why it might cause problems that other c-states avoid. > With C6 enabled, that state is used at > least sometimes (so C1E is used less often), but PC6 doesn't seem to be > really used - it looks like core C6 only is entered and which may be why C6 > adds less latency than C1E (and analogously for C3). > At the moment, I'm happy with either solution but mostly because I can't tell what other trade-offs should be considered :/ -- Mel Gorman SUSE Labs