linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wyes Karny <wyes.karny@amd.com>
To: Dave Hansen <dave.hansen@intel.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 v2 2/3] x86: Remove vendor checks from prefer_mwait_c1_over_halt
Date: Fri, 6 May 2022 15:12:33 +0530	[thread overview]
Message-ID: <fa4e26df-d2e7-7b13-a961-4f741b319e79@amd.com> (raw)
In-Reply-To: <0b501f18-a6b8-1d9b-e72a-ea6cb33720a2@intel.com>

Hello Dave,

On 5/5/2022 10:34 PM, Dave Hansen wrote:
> On 5/5/22 04:01, Wyes Karny wrote:
>> -	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;
>> +
>> +	/* Monitor has a bug. Fallback to HALT */
>> +	if (boot_cpu_has_bug(X86_BUG_MONITOR))
>>  		return 0;
>>  
>> -	if (!cpu_has(c, X86_FEATURE_MWAIT) || boot_cpu_has_bug(X86_BUG_MONITOR))
>> +	if (c->cpuid_level < CPUID_MWAIT_LEAF)
>>  		return 0;
> 
> First of all, thanks for all the detail in this new version of the patches!
> 
> In arch/x86/kernel/cpu/common.c, we have:
> 
> cpuid_dependent_features[] = {
>         { X86_FEATURE_MWAIT,            0x00000005 },
> 	...
> 
> Shouldn't that clear X86_FEATURE_MWAIT on all systems without
> CPUID_MWAIT_LEAF?  That would make the c->cpuid_level check above
> unnecessary.

Agreed. I will update it in the next version.

> 
>> +	/*
>> +	 * If ECX doesn't have extended info about MWAIT,
>> +	 * don't need to check substates.
>> +	 */
>> +	if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED))
>> +		return 1;
> 
> Could you explain a bit more about this?  I don't know this CPUID leaf
> off the top of my head and the line after this is checking EDX.  It's
> not apparent from this comment why "!ECX_EXTENSIONS_SUPPORTED" means
> that MWAIT should be preferred.

MWAIT can be used for two cases - address range monitoring and advanced power management.

According to Intel Architectures Software Developer’s Manual, Volume2B:

"MWAIT accepts a hint and optional extension to the processor that it 
can enter a specified target C state while waiting for an event or a store 
operation to the address range armed by MONITOR. Support for MWAIT extensions
for power management is indicated by CPUID.05H:ECX[bit 0] reporting 1.

EAX and ECX are used to communicate the additional information to the MWAIT instruction,
such as the kind of optimized state the processor should enter.

ECX specifies optional extensions for the MWAIT instruction.
EAX may contain hints such as the preferred optimized state the processor should enter."

So, if CPUID.05H:ECX[0] = 0, MWAIT extensions are not available (not allowed) and hence 
it is safe to use MWAIT with EAX=0,ECX=0. Otherwise, we have to check CPUID.05H:EDX[bit 7:4]
to get the number of C1 substates and this should be greater than equal to 1.

> 
>> +	/* Check, whether at least 1 MWAIT C1 substate is present */
>> +	return (edx & MWAIT_C1_SUBSTATE_MASK);
> 

Thanks,
Wyes


  reply	other threads:[~2022-05-06  9:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 10:48 [PATCH v2 0/3] x86: Prefer MWAIT over HALT on AMD processors Wyes Karny
2022-05-05 10:48 ` [PATCH v2 1/3] x86: Use HALT in default_idle when idle=nomwait cmdline arg is passed Wyes Karny
2022-05-05 17:13   ` Dave Hansen
2022-05-06 11:23     ` Wyes Karny
2022-05-05 11:01 ` [PATCH v2 2/3] x86: Remove vendor checks from prefer_mwait_c1_over_halt Wyes Karny
2022-05-05 17:04   ` Dave Hansen
2022-05-06  9:42     ` Wyes Karny [this message]
2022-05-06 15:52       ` Dave Hansen
2022-05-06 18:19         ` Wyes Karny
2022-05-05 11:04 ` [PATCH v2 3/3] x86: Fix comment for X86_FEATURE_ZEN Wyes Karny
2022-05-05 17:10   ` Dave Hansen
2022-05-05 18:55     ` 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=fa4e26df-d2e7-7b13-a961-4f741b319e79@amd.com \
    --to=wyes.karny@amd.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).