From: Reinette Chatre <reinette.chatre@intel.com>
To: Babu Moger <babu.moger@amd.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
"bp@alien8.de" <bp@alien8.de>,
"tony.luck@intel.com" <tony.luck@intel.com>
Cc: "kuo-lang.tseng@intel.com" <kuo-lang.tseng@intel.com>,
"ravi.v.shankar@intel.com" <ravi.v.shankar@intel.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V3 1/4] x86/resctrl: Enable user to view and select thread throttling mode
Date: Thu, 14 May 2020 11:10:59 -0700 [thread overview]
Message-ID: <591cfbf0-fe1d-d96c-9842-79e62e76fbfe@intel.com> (raw)
In-Reply-To: <0d1fc0a8-7544-861e-a2f6-42c34ad798d9@amd.com>
Hi Babu,
Thank you very much for taking a look.
On 5/14/2020 9:45 AM, Babu Moger wrote:
> Hi Reinnette,
>
> The patches did not apply on my tree. I got the latest tree today. You
Which tree did you use as baseline? These patches should apply cleanly
on top of the other resctrl patches already queued for inclusion into
v5.8 as found on the x86/cache branch of the tip repo.
> might want to check again.
> Hunk #1 FAILED at 29.
> 1 out of 7 hunks FAILED -- saving rejects to file
> arch/x86/kernel/cpu/resctrl/rdtgroup.c.rej
>
>
>> -----Original Message-----
>> From: Reinette Chatre <reinette.chatre@intel.com>
>> Sent: Wednesday, May 6, 2020 6:50 PM
>> To: tglx@linutronix.de; fenghua.yu@intel.com; bp@alien8.de;
>> tony.luck@intel.com
>> Cc: kuo-lang.tseng@intel.com; ravi.v.shankar@intel.com; mingo@redhat.com;
>> Moger, Babu <Babu.Moger@amd.com>; hpa@zytor.com; x86@kernel.org;
>> linux-kernel@vger.kernel.org; Reinette Chatre <reinette.chatre@intel.com>
>> Subject: [PATCH V3 1/4] x86/resctrl: Enable user to view and select thread
>> throttling mode
>>
...
>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c
>> b/arch/x86/kernel/cpu/resctrl/core.c
>> index 12f967c6b603..1bc686777069 100644
>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>> @@ -250,6 +250,30 @@ static inline bool rdt_get_mb_table(struct rdt_resource
>> *r)
>> return false;
>> }
>>
>> +/*
>> + * Model-specific test to determine if platform where memory bandwidth
>> + * control is applied to a core can be configured to apply either the
>> + * maximum or minimum of the per-thread delay values.
>> + * By default, platforms where memory bandwidth control is applied to a
>> + * core will select the maximum delay value of the per-thread CLOS.
>> + *
>> + * NOTE: delay value programmed to hardware is inverse of bandwidth
>> + * percentage configured via user interface.
>> + */
>> +bool mba_cfg_supports_min_max_intel(void)
>> +{
>> + switch (boot_cpu_data.x86_model) {
>> + case INTEL_FAM6_ATOM_TREMONT_D:
>> + case INTEL_FAM6_ICELAKE_X:
>> + case INTEL_FAM6_ICELAKE_D:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +
>> + return false;
>> +}
>
> I see that you are calling this function multiple times. Why don't you
It is called:
- once during initialization
- once per package initialization (when first CPU on a package comes online)
- once per read from or write to the new "thread_throttle_mode" file
> make it as a property in rdt_resource. Set it only once during the
> init(may be in get_mem_config_intel). Then you can use it wherever
> required. This also probably help James to make everything architecture
> independent. What do you think?
If I understand correctly this would require understanding how each
architecture behaves in this regard to ensure the property within
rdt_resource is initialized correctly. While it could just be set within
get_mem_config_intel as you suggest, this property would be present in
AMD's resource and thus need a value ... could you please provide
guidance what this property should be on AMD? I looked at the bandwidth
enforcement section of
https://developer.amd.com/wp-content/resources/56375.pdf but it is not
obvious to me where bandwidth is actually enforced and how this
enforcement is affected when threads and/or cores are running tasks with
different CLOS that have different bandwidth limits assigned.
With AMD's properties understood then the new "thread_throttle_mode"
file could be visible on all platforms, not just Intel, and display
accurate values for all and be architecture independent.
Alternatively, the new property could have values: UNDEFINED, MIN, MAX,
or PER_THREAD ... with AMD having UNDEFINED and the
"thread_throttle_mode" continues to be visible on Intel platforms only.
I would appreciate your thoughts on this.
> I assume that this property is probably not part of CPUID.
Correct. This specific property is model specific, but also transient in
that it is replaced by X86_FEATURE_PER_THREAD_MBA (that is part of
CPUID) in future platforms.
Reinette
next prev parent reply other threads:[~2020-05-14 18:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 23:49 [PATCH V3 0/4] " Reinette Chatre
2020-05-06 23:49 ` [PATCH V3 1/4] " Reinette Chatre
2020-05-14 16:45 ` Babu Moger
2020-05-14 18:10 ` Reinette Chatre [this message]
2020-05-14 20:06 ` Babu Moger
2020-05-16 18:00 ` Reinette Chatre
2020-05-06 23:49 ` [PATCH V3 2/4] x86/resctrl: Enumerate per-thread MBA Reinette Chatre
2020-05-14 19:04 ` Babu Moger
2020-05-14 20:12 ` Reinette Chatre
2020-05-14 20:41 ` Babu Moger
2020-05-06 23:49 ` [PATCH V3 3/4] x86/resctrl: Enable " Reinette Chatre
2020-05-14 19:04 ` Babu Moger
2020-05-16 18:03 ` Reinette Chatre
2020-05-06 23:49 ` [PATCH V3 4/4] x86/resctrl: Use appropriate API for strings terminated by newline Reinette Chatre
2020-05-14 19:05 ` Babu Moger
2020-05-14 19:11 ` Andy Shevchenko
2020-05-14 20:06 ` Babu Moger
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=591cfbf0-fe1d-d96c-9842-79e62e76fbfe@intel.com \
--to=reinette.chatre@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=kuo-lang.tseng@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®