Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp2110142iob; Fri, 20 May 2022 02:08:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzugTiuYc6Bv5KdAYlKojtsiUA5Nxzp0/45U9OJMej0MnHtOrO5I84EilllUeeZBVy/kBk X-Received: by 2002:a63:4f4a:0:b0:3f5:d2b1:8dc4 with SMTP id p10-20020a634f4a000000b003f5d2b18dc4mr7670393pgl.106.1653037725459; Fri, 20 May 2022 02:08:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653037725; cv=none; d=google.com; s=arc-20160816; b=gsr+Fm9iWaqB4+pReg8koZAhslsChMsZQHI6NWBql80go0NMKzYN30dxITDuIkmP/a H8RYtHapdufkDBAQmYhkWiQR2QsAEkI/z5gf7dBakF83+j26saUVtgfyh61on9EiIltp v1t7/4BpCExNq6fcPiIZZflT9PgoeDu2YrR2KKbCQnyIfXUhgWH180JITQ+SqKNGGDzF vNuUpiopnE6TSXaDFRE7kTX4Wc+mCNkdeEceMnJejiEoNvNVi1twSyey3IC5hMWWSr/q h+hC30cP+MRHmXxtdUhct8Xpw6Px90Rh/AKdrof2wr707pznQuSSj9tTxO7B8fRPOatr nHdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=xpXmkK/CoU4IvZX4YvBQ2p2rY8YIAA2+K+AfVgcH1/M=; b=jfyMZQBg3mRI4PwRG2iHePGEJMgG1bSSNlTT94bWy46Xm6Nw0Athwb2g80z0NDqeFr 6ZUz6zn7f9lYu13mbwqBr8J9nfTYjGZJGXk96JYytcvMIWLeU8Gz5FWFzQKgTkRD07kX oBQGo2XwS/3QHjZ9DBjQmA2MbKtU1G6fxTwHc4H+w0hxMrxZy0qPzVKR2OnaF8NHV8Xd TtlMHTgnVLMSuR1nJJSlRNV6hQi2FQfWg8FU9y+tjGE0oSzsH6zhAdiDZBkWkSrLcQFm +F4/jK/1jkB1h9FboPY9SOhyPkG6XA9V3mT3DzDAp7yDso9eW6ctCFiL/XoXqQn8ZBhD vNnQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=i4fGDU9V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g6-20020a633746000000b003c17c1ae2acsi8730692pgn.230.2022.05.20.02.08.32; Fri, 20 May 2022 02:08:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=i4fGDU9V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241563AbiESQAh (ORCPT + 99 others); Thu, 19 May 2022 12:00:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233730AbiESQAf (ORCPT ); Thu, 19 May 2022 12:00:35 -0400 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F52EA0D01 for ; Thu, 19 May 2022 09:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652976034; x=1684512034; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=d0+Q8tZ0yi3/2AaQVtmSSJxoJMdSkTRdXPxoNfmt8PY=; b=i4fGDU9VeNJIOSZizdC+PIu5QUK0aocMtjsIL0jTdXhSs3u8aspDdfVs /GzkS5hVqdfYHA8UA/wSjBQe/rbnaW6USb5WyWmOkWCe0K9ZgXrBLeKC3 v467jDZLmABviFJ/1miIMzjI/UXyepIpQtTiJbgPBf8jFh6tPodi8Hb8z W7wJwISmr7PD9F1F+OlGD6sqMB5u7Z6B/lOprRT9E1OfVX5N67owAqNr/ Oy+l90ylTPZQPG6jx+B/ghjeYdK8NjLuKOY6XtWpMyvLMHD2JO28mKBug h4FIu0Tt9fX/CamR+2EzXB8ClUeMSXG3r9Rq1t/NJRDIBJaTSF/bL/m8M g==; X-IronPort-AV: E=McAfee;i="6400,9594,10352"; a="332881403" X-IronPort-AV: E=Sophos;i="5.91,237,1647327600"; d="scan'208";a="332881403" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2022 09:00:33 -0700 X-IronPort-AV: E=Sophos;i="5.91,237,1647327600"; d="scan'208";a="606555168" Received: from rlsharma-mobl.amr.corp.intel.com (HELO [10.212.180.228]) ([10.212.180.228]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2022 09:00:33 -0700 Message-ID: Date: Thu, 19 May 2022 09:00:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v3 2/3] x86: Remove vendor checks from prefer_mwait_c1_over_halt Content-Language: en-US To: 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 References: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham 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 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; > > - 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?