All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhang Rui <rui.zhang@intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Wyes Karny <wyes.karny@amd.com>,
	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
Subject: Re: [PATCH v3 2/3] x86: Remove vendor checks from prefer_mwait_c1_over_halt
Date: Fri, 20 May 2022 21:43:59 +0800	[thread overview]
Message-ID: <410f36ccecb36644e196d71fef6e46bdc186b409.camel@intel.com> (raw)
In-Reply-To: <b1c9fd6c-9f00-9662-d590-b52ce26d0aca@intel.com>

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.

thanks,
rui


  parent reply	other threads:[~2022-05-20 13:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 10:18 [PATCH v3 0/3] x86: Prefer MWAIT over HLT on AMD processors Wyes Karny
2022-05-10 10:18 ` [PATCH v3 1/3] x86: Use HLT in default_idle when idle=nomwait cmdline arg is passed Wyes Karny
2022-05-20 15:38   ` Zhang Rui
2022-05-23  5:02     ` Wyes Karny
2022-05-10 10:18 ` [PATCH v3 2/3] x86: Remove vendor checks from prefer_mwait_c1_over_halt Wyes Karny
2022-05-19 16:00   ` Dave Hansen
2022-05-20 11:27     ` Wyes Karny
2022-05-20 13:43     ` Zhang Rui [this message]
2022-05-20 15:46       ` Zhang Rui
2022-05-23 15:49       ` Wyes Karny
2022-05-25  7:20         ` Zhang Rui
2022-05-10 10:18 ` [PATCH v3 3/3] x86: Fix comment for X86_FEATURE_ZEN Wyes Karny
2022-05-19 10:13 ` [PATCH v3 0/3] x86: Prefer MWAIT over HLT on AMD processors Wyes Karny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=410f36ccecb36644e196d71fef6e46bdc186b409.camel@intel.com \
    --to=rui.zhang@intel.com \
    --cc=Ananth.Narayan@amd.com \
    --cc=Lewis.Carroll@amd.com \
    --cc=Mario.Limonciello@amd.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bharata@amd.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gautham.shenoy@amd.com \
    --cc=hpa@zytor.com \
    --cc=jing2.liu@intel.com \
    --cc=jmattson@google.com \
    --cc=keescook@chromium.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=metze@samba.org \
    --cc=mingo@redhat.com \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=peterz@infradead.org \
    --cc=puwen@hygon.cn \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tglx@linutronix.de \
    --cc=wyes.karny@amd.com \
    --cc=x86@kernel.org \
    --cc=zhengqi.arch@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.