public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Moger, Babu" <Babu.Moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
	"vikas.shivappa@linux.intel.com" <vikas.shivappa@linux.intel.com>,
	"tony.luck@intel.com" <tony.luck@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"pombredanne@nexb.com" <pombredanne@nexb.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
	"bp@suse.de" <bp@suse.de>,
	"rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>,
	"ak@linux.intel.com" <ak@linux.intel.com>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"xiaochen.shen@intel.com" <xiaochen.shen@intel.com>,
	"colin.king@canonical.com" <colin.king@canonical.com>,
	"Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
	"Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
	"luto@kernel.org" <luto@kernel.org>,
	"jroedel@suse.de" <jroedel@suse.de>,
	"jannh@google.com" <jannh@google.com>,
	"dima@arista.com" <dima@arista.com>,
	"jpoimboe@redhat.com" <jpoimboe@redhat.com>,
	"vkuznets@redhat.com" <vkuznets@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 03/10] arch/x86: Re-arrange RDT init code
Date: Tue, 2 Oct 2018 23:41:18 +0000	[thread overview]
Message-ID: <ec7ea236-adca-246c-2d2a-56dc68a146f8@amd.com> (raw)
In-Reply-To: <09e1f4dc-7882-9bb4-f5a7-e9e7caafee84@intel.com>

Hi Reinette,
Thanks for the review. My response below.

On 10/02/2018 02:21 PM, Reinette Chatre wrote:
> Hi Babu,
> 
> On 9/24/2018 12:19 PM, Moger, Babu wrote:
>> Re-organize the RDT init code. Separate the call sequence for each
>> feature. That way, it is easy to call quirks or features separately
>> for each vendor if there are differences.
>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
>>  arch/x86/kernel/cpu/rdt.c | 44 ++++++++++++++++++++++++++++-----------
>>  1 file changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/rdt.c b/arch/x86/kernel/cpu/rdt.c
>> index b361c63170d7..736715b81fd8 100644
>> --- a/arch/x86/kernel/cpu/rdt.c
>> +++ b/arch/x86/kernel/cpu/rdt.c
>> @@ -813,10 +813,6 @@ static __init bool get_rdt_alloc_resources(void)
>>  		ret = true;
>>  	}
>>  
>> -	if (rdt_cpu_has(X86_FEATURE_MBA)) {
>> -		if (rdt_get_mem_config(&rdt_resources_all[RDT_RESOURCE_MBA]))
>> -			ret = true;
>> -	}
> 
> The commit message mentions that the call sequence for each feature is
> separated, but here only the MBA feature is separated.

Yes. MBA and quirks are separated. I will fix the commit message. I
overlooked some of the errors returned by these functions. Let me go back
and update this patch. Will keep mostly as is. Only separate MBA and
quirks which are important. Will make sure errors are propagated properly.

> 
> The MBA feature detection is removed above .... (more later)
> 
>>  	return ret;
>>  }
>>  
>> @@ -831,11 +827,12 @@ static __init bool get_rdt_mon_resources(void)
>>  
>>  	if (!rdt_mon_features)
>>  		return false;
>> +	else
>> +		return true;
>>  
>> -	return !rdt_get_mon_l3_config(&rdt_resources_all[RDT_RESOURCE_L3]);
>>  }
>>  
>> -static __init void rdt_quirks(void)
>> +static __init void rdt_quirks_intel(void)
>>  {
>>  	switch (boot_cpu_data.x86_model) {
>>  	case INTEL_FAM6_HASWELL_X:
>> @@ -850,13 +847,22 @@ static __init void rdt_quirks(void)
>>  	}
>>  }
>>  
>> -static __init bool get_rdt_resources(void)
>> +static __init void rdt_quirks(void)
>>  {
>> -	rdt_quirks();
>> -	rdt_alloc_capable = get_rdt_alloc_resources();
>> -	rdt_mon_capable = get_rdt_mon_resources();
>> +	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
>> +		rdt_quirks_intel();
>> +}
>> +
>> +static __init void rdt_detect_l3_mon(void)
>> +{
>> +	if (rdt_mon_capable)
>> +		rdt_get_mon_l3_config(&rdt_resources_all[RDT_RESOURCE_L3]);
> 
> The possible errors from this configuration is now lost.

Yes. I overlooked it. Same comment as above. Let me go back and update
this patch.
> 
>> +}
>>  
>> -	return (rdt_mon_capable || rdt_alloc_capable);
>> +static __init void rdt_check_mba(void)
>> +{
>> +	if (rdt_cpu_has(X86_FEATURE_MBA))
>> +		rdt_get_mem_config(&rdt_resources_all[RDT_RESOURCE_MBA]);
> 
> Here too the possible failure of this configuration is now lost.

Ditto.. Let me go back and update this patch.

> 
>>  }
>>  
>>  static enum cpuhp_state rdt_online;
>> @@ -866,8 +872,22 @@ static int __init rdt_late_init(void)
>>  	struct rdt_resource *r;
>>  	int state, ret;
>>  
>> -	if (!get_rdt_resources())
>> +	/* Run quirks first */
>> +	rdt_quirks();
>> +
>> +	rdt_alloc_capable = get_rdt_alloc_resources();
>> +	rdt_mon_capable = get_rdt_mon_resources();
>> +
>> +	if (!(rdt_alloc_capable || rdt_mon_capable)) {
>> +		pr_info("RDT allocation or monitoring not detected\n");
> 
> This function ends with a log entry for every resource discovered. Is
> this new log entry needed to indicate that such resources have not been
> found? Could it not just be the absence of the other message?

As this is relatively new feature, so I added this info message. It helped
me debug what went wrong. Otherwise, I don't see anything. I can remove it
if the message is too annoying to the user.

> 
>>  		return -ENODEV;
>> +	}
> 
> ... (continued from above) ... since the MBA feature detection was
> removed from get_rdt_alloc_resources() would the above not cause failure
> on systems that only support MBA?

yes. Let me go back and update this patch.
> 
>> +
>> +	/* Detect l3 monitoring resources */
> 
> I do not think this comment is accurate ... has the monitoring resources
> not been detected earlier in get_rdt_mon_resources() and now they will
> be configured?
> 
>> +	rdt_detect_l3_mon();
>> +
>> +	/* Check for Memory Bandwidth Allocation */
>> +	rdt_check_mba();
> 
> To follow up on above .. the potential failure of these configurations
> are now lost here. Initialization should not continue if these
> configurations failed.

Yes. Let me go back and update this patch.

> 
>>  
>>  	rdt_init_padding();
>>  
>>
> 
> Reinette
> 

  reply	other threads:[~2018-10-02 23:41 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-24 19:18 [RFC PATCH 00/10] arch/x86: AMD QoS support Moger, Babu
2018-09-24 19:18 ` [RFC PATCH 01/10] arch/x86: Start renaming the rdt files to more generic names Moger, Babu
2018-09-24 19:18 ` [RFC PATCH 02/10] arch/x86: Rename the RDT functions and definitions Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 03/10] arch/x86: Re-arrange RDT init code Moger, Babu
2018-10-02 19:21   ` Reinette Chatre
2018-10-02 23:41     ` Moger, Babu [this message]
2018-10-03 18:54       ` Reinette Chatre
2018-10-03 20:12         ` Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 04/10] arch/x86: Introduce a new config parameter PLATFORM_QOS Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 05/10] arch/x86: Use new config parameter PLATFORM_QOS for compilation Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 06/10] arch/x86: Initialize the resource functions that are different Moger, Babu
2018-10-02 22:06   ` Reinette Chatre
2018-10-03 15:25     ` Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 07/10] arch/x86: Bring few more functions into the resource structure Moger, Babu
2018-10-02 22:07   ` Reinette Chatre
2018-10-03 15:32     ` Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 08/10] arch/x86: Introduce new config parameter AMD_QOS Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 09/10] arch/x86: Add AMD feature bit X86_FEATURE_MBA in cpuid bits array Moger, Babu
2018-09-24 19:19 ` [RFC PATCH 10/10] arch/x86: Introduce QOS feature for AMD Moger, Babu
2018-10-02 18:27   ` Fenghua Yu
2018-10-03 15:56     ` Moger, Babu
2018-10-02 22:13   ` Reinette Chatre
2018-10-03 17:21     ` Moger, Babu
2018-10-05 16:20   ` James Morse
2018-10-05 17:18     ` Moger, Babu
2018-09-27 20:14 ` [RFC PATCH 00/10] arch/x86: AMD QoS support Thomas Gleixner
2018-09-28  1:57   ` Moger, Babu
2018-10-05 16:18     ` James Morse
2018-10-05 17:03       ` Moger, Babu
2018-10-02 17:06 ` Fenghua Yu
2018-10-02 17:44   ` Moger, Babu
2018-10-02 18:46     ` Fenghua Yu
2018-10-02 19:16       ` Moger, Babu
2018-10-03 18:52         ` Fenghua Yu
2018-10-03 19:48           ` Thomas Gleixner
2018-10-03 20:09           ` Moger, Babu
2018-10-05 16:19             ` James Morse

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=ec7ea236-adca-246c-2d2a-56dc68a146f8@amd.com \
    --to=babu.moger@amd.com \
    --cc=Thomas.Lendacky@amd.com \
    --cc=ak@linux.intel.com \
    --cc=bp@suse.de \
    --cc=colin.king@canonical.com \
    --cc=dima@arista.com \
    --cc=dwmw@amazon.co.uk \
    --cc=fenghua.yu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pombredanne@nexb.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=reinette.chatre@intel.com \
    --cc=sherry.hurwitz@amd.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vikas.shivappa@linux.intel.com \
    --cc=vkuznets@redhat.com \
    --cc=x86@kernel.org \
    --cc=xiaochen.shen@intel.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