Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5120505pxj; Wed, 9 Jun 2021 09:34:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzILJer3ynEuZcOJXGqINm2oQcjHuMiOMglpcqWtAsO3E+SCNLD4K1S/kQ+mFe6G5bf4zZj X-Received: by 2002:a05:6402:31ba:: with SMTP id dj26mr304413edb.71.1623256476404; Wed, 09 Jun 2021 09:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623256476; cv=none; d=google.com; s=arc-20160816; b=HjtK4Z19e5VFolqgC0mC1GQAebPCzsGrvxbhMytf+TRYf3qhuy1UVeGYLWciluiztH zPzzQIe3DdsEXZdwM58Wwg7GGImD0crWv59qOAQL8a05UnraDrC1M5EJPJar9tgKEPiX zd7voSTV0+dT1WutbnAUKhgBRJh/dfrPi4I+dIbK1IFX7nQGDFt+9z13Bl8FBk9drhXV VoSxyu+qoqd718/z9SPcnrnbFqaBTA3CyHwVTHNBS7iL7aKQE1BXwMgWoJDWLNyLZ7BX G8RWy2mhFqr3gxc+T+1x3CohhQ5EswwASKQIMaHRdvR7p0lgtn3aj5Qs8F9zhUohxLh5 IZBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=GePodMOee0azACNFHtOPRzOQtkdj5aSzI6hkdk+H1q0=; b=oXwhqxRdQMPfZpuiJstLKPi/n3a//OKnNQqIif15B8DEPvo0fhFWJybUuVs176DD2W a+/9s2nWP/7xu4oOPwxhJ+dEF26MfNFlNzCg/GPF+/ComFY98XAPZd6nuEi510Sht45G a2VlrXzOPF4XA/KXjaIfkvuVksbjcMktfD+POIbJGSHg3qaR8vPZSQENrCPGtD3aqvt9 gMncQlHyu40wN8h+FuTCbi1Y71GZU++eM17KGDUMMgjmADTIheYb+DEUWt0WrghdD1be 9MvaSvZanQ6HdUQvyvyJpgbs9Qk0VgwIHen39KngWbavCGctxiNe9OzuiKx6ambG1n7G QM0g== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k11si154105edi.278.2021.06.09.09.34.12; Wed, 09 Jun 2021 09:34:36 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237405AbhFIPz0 (ORCPT + 99 others); Wed, 9 Jun 2021 11:55:26 -0400 Received: from mail-oi1-f177.google.com ([209.85.167.177]:36661 "EHLO mail-oi1-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237163AbhFIPzZ (ORCPT ); Wed, 9 Jun 2021 11:55:25 -0400 Received: by mail-oi1-f177.google.com with SMTP id a21so25564326oiw.3; Wed, 09 Jun 2021 08:53:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GePodMOee0azACNFHtOPRzOQtkdj5aSzI6hkdk+H1q0=; b=YNnGETb17eWKvd+m4ZFdeEfNWhCsxvRnQb0RsbuoMPu8xJuM+UE7pos8Q5+EuGa+PQ EFjUIHzUNU2sq/J+icsn7oQwd6keFR8vNflAviGj085zDEdI4M9yswkK18aBa1LHBEFd iZoQz/LTfpkrC2QELocUZjIulfm/c9uGQP4b8ACYXTVmNsDbakZ7HF+oG3BfCrJL9bW6 YMuQFBfQICIHXYrOCBekMiUEvne74SWoGW6hjJwg3YN7jGmJjfuEhiCHYvJz5S8POD6h AbGLtb10B9Rtvek6g6MAy61g7wg488Rt6EvKkrs6Ej6fatCNd34iH2L3rwea82ZgeR/+ tHnA== X-Gm-Message-State: AOAM531DDPkax3DOu3EvmfrPJ0BRN1Ono/6t6hCXolQVATppqbVWo2Tb H7KJLU6ZXrfGpNkcUWPgiB7bpJkGo5pc5PVQtPw= X-Received: by 2002:aca:650d:: with SMTP id m13mr7053680oim.157.1623254010275; Wed, 09 Jun 2021 08:53:30 -0700 (PDT) MIME-Version: 1.0 References: <20210528032054.7572-1-yu.c.chen@intel.com> In-Reply-To: <20210528032054.7572-1-yu.c.chen@intel.com> From: "Rafael J. Wysocki" Date: Wed, 9 Jun 2021 17:53:19 +0200 Message-ID: Subject: Re: [PATCH][v2] intel_idle: Adjust the SKX C6 latency and residency if PC6 is disabled To: Chen Yu Cc: Linux PM , "Rafael J. Wysocki" , Len Brown , Artem Bityutskiy , Zhang Rui , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 28, 2021 at 5:16 AM Chen Yu wrote: > > Currently cpuidle assumes worst-case C-state parameters, and so C6 > is described with PC6 parameters, which is worst case for requesting > CC6. When PC6 is enabled, this is appropriate. But if PC6 is disabled > in BIOS, the exit latency and target_residency should be adjusted > accordingly. > > Exit latency: > Previously the C6 exit latency was measured when woken up from CC6/PC6. > With PC6 disabled, the C6 exit latency should be CC6/PC0. > > Target residency: > With PC6 disabled, idle duration within [CC6, PC6) would make the > idle governor choose C1E over C6. This would cause low energy-efficiency. > We should lower the bar to request C6 when PC6 is disabled. > > To fill this gap, check if PC6 is disabled in the BIOS in the > MSR_PKG_CST_CONFIG_CONTROL(0xe2). If so, use CC6/PC0 parameters as the > new exit latency. Meanwhile, update target_residency to 3 times of the new > exit latency. This is consistent with how intel_idle driver uses _CST to > calculate the target_residency. The consequence is that, the OS would > be more offen to choose C6 over C1E when PC6 is disabled. This is reasonable > because if the user is using C6, it implies that the user cares about energy, > so choosing C6 more frequently is in accordance with user requirement. > > The new exit latency of CC6/PC0 92us was from wult[1] result on SKX, which was > measured via NIC wakeup from 99.99th latency. Besides SKX, the CLX and CPX > both have the same CPU model number. And since they have similar CC6 exit latency > to SKX, 96us and 89us respectively, reuse the value of SKX. > > There is concern that if we should introduce a more generic solution > rather than optimizing on each platforms. However consider the > code complexity and different PC6 bit interpretation on different > platforms, tune the code per platform seems to be an acceptable trade-off. > > [1] https://intel.github.io/wult/ > > Suggested-by: Len Brown > Signed-off-by: Chen Yu > --- > v2: Simplify the commit log to not mention C3/PC3. (Artem) > Confirm the exit latency on CLX and CPX.(Artem) > --- > drivers/idle/intel_idle.c | 33 +++++++++++++++++++++++++++++++++ > 1 file changed, 33 insertions(+) > > diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c > index ec1b9d306ba6..e6c543b5ee1d 100644 > --- a/drivers/idle/intel_idle.c > +++ b/drivers/idle/intel_idle.c > @@ -1484,6 +1484,36 @@ static void __init sklh_idle_state_table_update(void) > skl_cstates[6].flags |= CPUIDLE_FLAG_UNUSABLE; /* C9-SKL */ > } > > +/** > + * skx_idle_state_table_update - Adjust the Sky Lake/Cascade Lake > + * idle states table. > + */ > +static void __init skx_idle_state_table_update(void) > +{ > + unsigned long long msr; > + > + rdmsrl(MSR_PKG_CST_CONFIG_CONTROL, msr); > + > + /* > + * 000b: C0/C1 (no package C-state support) > + * 001b: C2 > + * 010b: C6 (non-retention) > + * 011b: C6 (retention) > + * 111b: No Package C state limits. > + */ > + if ((msr & 0x7) < 2) { > + /* > + * Uses the CC6 + PC0 latency and 3 times of > + * latency for target_residency if the PC6 > + * is disabled in BIOS. This is consistent > + * with how intel_idle driver uses _CST > + * to set the target_residency. > + */ > + skx_cstates[2].exit_latency = 92; > + skx_cstates[2].target_residency = 276; > + } > +} > + > static bool __init intel_idle_verify_cstate(unsigned int mwait_hint) > { > unsigned int mwait_cstate = MWAIT_HINT2CSTATE(mwait_hint) + 1; > @@ -1515,6 +1545,9 @@ static void __init intel_idle_init_cstates_icpu(struct cpuidle_driver *drv) > case INTEL_FAM6_SKYLAKE: > sklh_idle_state_table_update(); > break; > + case INTEL_FAM6_SKYLAKE_X: > + skx_idle_state_table_update(); > + break; > } > > for (cstate = 0; cstate < CPUIDLE_STATE_MAX; ++cstate) { > -- Applied as 5.14 material with some edits in the subject and changelog. Thanks!