Received: by 2002:ac2:464d:0:0:0:0:0 with SMTP id s13csp3290781lfo; Mon, 23 May 2022 00:51:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyiGwa0+TUkvin2Y2wCJDX3nwQ3nym/NhbW8gG2JFqV5aN+TtZ97i6htILNkUUMcG/XFgum X-Received: by 2002:a17:90a:e388:b0:1df:ac20:df7d with SMTP id b8-20020a17090ae38800b001dfac20df7dmr25820168pjz.208.1653292277112; Mon, 23 May 2022 00:51:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653292277; cv=none; d=google.com; s=arc-20160816; b=VaHlp4dfV8JJ7Of87Ct/ui60bZU0UUtvlG8jzMp23tJKyuyZ4t3EAlVT/p+zncCAFI JI182BXO/KxZuk10LZwycH6doYj0RPkAkYFUGNnpKkfpOfF20gNuHPiuMM1WhI6XWIms DdFkMgQxo+JHmxKPDHnQmxtEkP0gveFvyAwtt8UT+fA7Hf04fsdEUZTAaaIv/drKrawv fYsBNCa+x1DZUzkaT6QSyT0xFAR9upJAoX7oECgEoz95RPShCePlws84+O/ep1jZJqkI ngZYf9yObrcFZiQd5rsJX3vAwbSfqt7cz1J7orYFDOFvjEol08oXJSlWEXmclSAVZqe5 6YLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=NYNMuBu/lyMCZcHJgvmjYR2kdmLaWrsRymNDVj56mlg=; b=u9OwsXEsTOoxUfN05R4iHHSJ9Z1NDeVYxjJbHs+xUIean/tYoBWlJkajM7/Iw4MIUC 1kHGbQpihsEc61dmPZSVOfjYc85/XeClAyleQrwkZ4+N1emre4+faBgMznGgSPPyXW4O 0KJZ+81wDNcAb9y1xbjLiWbiwEp9In+huKv5BAxC28SiZ4k/QuHgmIOtgyBlCjVFAREe xp0xI/PF1JFOuh4Pc6jZs9moH3M97LkIIS6zHehlBb4B9eBnacAknvEb26HwaxIr/1fZ 643vvEj9RC5S/y05lnI/szjomeIhCPDcO1ZLRIjVcjE6Ow/UYr92eoHHCVSI9/jLoPZl ADow== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="T+J2/Rxe"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id bj7-20020a170902850700b0015e6330c0ecsi8653169plb.330.2022.05.23.00.51.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 00:51:17 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="T+J2/Rxe"; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0E1B522407E; Sun, 22 May 2022 23:54:50 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237452AbiETPqh (ORCPT + 99 others); Fri, 20 May 2022 11:46:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351243AbiETPqQ (ORCPT ); Fri, 20 May 2022 11:46:16 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C02395AA64 for ; Fri, 20 May 2022 08:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653061573; x=1684597573; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=JwAQQFiNniZWQWykR1w1dfYJzoYw0slCncYbLV54olY=; b=T+J2/RxehLqR0PW2GpUHN+F6xJcLuOa5YCTaE5WrDIY5ReVoRo4GZVGR /QHKyHYjtQZehDkJS404LKLwwFbX7erdiMDgOZ8G4bUAH6ZTJ3O8NG7An /M7eRmp9TpDB1mbL2LfRfJO2AxXEmMly41NVDZOAJFHKTOfJWSJk4y0ib m1e0sUSzvUu/7ozKe1Avj+BpkMBIEk6VgWTdy7AZSb/jvyiD9BzcWwOYl Dqlack21FeWtAnwmT4qz4Suw4KFegom86JxZQKsFRSYSQb8fkGn6AXraG qNSCNddDh26ORtnaBZVRHsfWrFMtF6UEHMvLR2tndkCTcneAApDkFyPKJ w==; X-IronPort-AV: E=McAfee;i="6400,9594,10353"; a="270224197" X-IronPort-AV: E=Sophos;i="5.91,239,1647327600"; d="scan'208";a="270224197" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2022 08:46:09 -0700 X-IronPort-AV: E=Sophos;i="5.91,239,1647327600"; d="scan'208";a="715579968" Received: from yyan7-mobl1.ccr.corp.intel.com ([10.255.31.53]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 May 2022 08:46:03 -0700 Message-ID: <43da52e2c07f56f548a6543b7d15bcd4b192cfbf.camel@intel.com> Subject: Re: [PATCH v3 2/3] x86: Remove vendor checks from prefer_mwait_c1_over_halt From: Zhang Rui To: Dave Hansen , Wyes Karny , linux-kernel@vger.kernel.org Cc: Lewis.Carroll@amd.com, Mario.Limonciello@amd.com, gautham.shenoy@amd.com, Ananth.Narayan@amd.com, bharata@amd.com, len.brown@intel.com, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, peterz@infradead.org, chang.seok.bae@intel.com, keescook@chromium.org, metze@samba.org, zhengqi.arch@bytedance.com, mark.rutland@arm.com, puwen@hygon.cn, rafael.j.wysocki@intel.com, andrew.cooper3@citrix.com, jing2.liu@intel.com, jmattson@google.com, pawan.kumar.gupta@linux.intel.com Date: Fri, 20 May 2022 23:46:01 +0800 In-Reply-To: <410f36ccecb36644e196d71fef6e46bdc186b409.camel@intel.com> References: <410f36ccecb36644e196d71fef6e46bdc186b409.camel@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2022-05-20 at 21:43 +0800, Zhang Rui wrote: > On Thu, 2022-05-19 at 09:00 -0700, Dave Hansen wrote: > > On 5/10/22 03:18, Wyes Karny wrote: > > > static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 > > > *c) > > > { > > > + u32 eax, ebx, ecx, edx; > > > + > > > /* User has disallowed the use of MWAIT. Fallback to HALT */ > > > if (boot_option_idle_override == IDLE_NOMWAIT) > > > return 0; > > > > > > - if (c->x86_vendor != X86_VENDOR_INTEL) > > > + /* MWAIT is not supported on this platform. Fallback to HALT */ > > > + if (!cpu_has(c, X86_FEATURE_MWAIT)) > > > return 0; > > I'm new to x86 code, a dumb question, what about the other vendors? > with this patch, prefer_mwait_c1_over_halt() can return 1 for other > vendors as well? > > > > > > > - if (!cpu_has(c, X86_FEATURE_MWAIT) || > > > boot_cpu_has_bug(X86_BUG_MONITOR)) > > > + /* Monitor has a bug. Fallback to HALT */ > > > + if (boot_cpu_has_bug(X86_BUG_MONITOR)) > > > return 0; > > > > So, before, we pretty much just assume that all Intel CPUs with > > MWAIT > > should use MWAIT C1. > > > > > - return 1; > > > + cpuid(CPUID_MWAIT_LEAF, &eax, &ebx, &ecx, &edx); > > > + > > > + /* > > > + * If MWAIT extensions are not available, it is safe to use > > > MWAIT > > > + * with EAX=0, ECX=0. > > > + */ > > > + if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED)) > > > + return 1; > > > + > > > + /* > > > + * If MWAIT extensions are available, there should be least one > > > + * MWAIT C1 substate present. > > > + */ > > > + return (edx & MWAIT_C1_SUBSTATE_MASK); > > > } > > > > So, I guess the "If MWAIT extensions are not available" check is > > consistent with the "always use it on Intel" behavior. > > > > But, this would change the behavior on Intel systems that both have > > CPUID5_ECX_EXTENSIONS_SUPPORTED and do not set bits in > > MWAIT_C1_SUBSTATE_MASK. > > > > Is that a problem or an improvement? > > At least Intel processors since Nehalem have MWAIT C1 support. > For elder ones, need to confirm with Len. > > When no bits set in MWAIT_C1_SUBSTATE_MASK, it means MWAIT C1 is not > available for some reason, let me check if I can make this happen or > not in real life. I tried an Icelake server and a whiskeylake client, the supported cstates in CPUID(5) edx doesn't change when a specific cstate or all cstates are enabled/disabled in BIOS. So there are always bits set in MWAIT_C1_SUBSTATE_MASK, and this patch doesn't make any change to these Intel processors that have MWAIT C1 support. thanks, rui