| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 4 Jan 2023 12:01:13 -0600
From: "Moger, Babu" <babu.moger@....com>
To: Stephane Eranian <eranian@...gle.com>,
"Yu, Fenghua" <fenghua.yu@...el.com>
Cc: "Chatre, Reinette" <reinette.chatre@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"corbet@....net" <corbet@....net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"peternewman@...gle.com" <peternewman@...gle.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: Re: [RFC PATCH 3/3] x86/resctrl: Display the RMID and COSID for
resctrl groups
Hi Stephane,
On 1/4/23 00:45, Stephane Eranian wrote:
> On Tue, Jan 3, 2023 at 10:06 PM Yu, Fenghua <fenghua.yu@...el.com> wrote:
>> Hi, Babu,
>>
>>> When a user creates a control or monitor group, the CLOSID or RMID are not
>>> visible to the user. These are architecturally defined entities.
>>> There is no harm in displaying these in resctrl groups. Sometimes it can help to
>>> debug the issues.
>> Although "no harm" to show them, it's not useful for generic user either and may
>> cause confusion sometimes. CLOSID and RMID are supposed to be invisible to
>> generic users.
>>
>> Maybe introduce a new resctrl mount option called "debug" and show the files
>> and maybe other future debug info only in debug mode?
>>
> On other non-x86 architectures, these have no meaning or no direct mapping.
> Take ARM MPAM, it is called PARTID and it does not map to either RMID
> or CLOSID, it is combined.
> Why would you call this closid/rmid at the user level?
> You could instead use a more generic name such as mon_hw_id,
> ctrl_hw_id. And on ARM they would be the same.
> Just my suggestion.
Sure. We can change the names to mon_hw_id and ctrl_hw_id.
Thanks
Babu
>
>
>>> Add CLOSID and RMID to the control/monitor groups display in resctrl interface.
>>>
>>> $cat /sys/fs/resctrl/clos1/closid
>>> 1
>>> $cat /sys/fs/resctrl/mon_groups/mon1/rmid
>>> 3
>>>
>>> Signed-off-by: Babu Moger <babu.moger@....com>
>>> ---
>>> Documentation/x86/resctrl.rst | 15 ++++++++++
>>> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 46
>>> ++++++++++++++++++++++++++++++++
>>> 2 files changed, 61 insertions(+)
>>>
>>> diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst
>>> index f26e16412bcb..8520514bc8b5 100644
>>> --- a/Documentation/x86/resctrl.rst
>>> +++ b/Documentation/x86/resctrl.rst
>>> @@ -231,6 +231,14 @@ All groups contain the following files:
>>> Just like "cpus", only using ranges of CPUs instead of bitmasks.
>>>
>>>
>>> +"rmid":
>>> + Reading this file shows the resource monitoring id (RMID) for
>>> + monitoring the resource utilization. Monitoring is performed by
>>> + tagging each core(or thread) or process via a Resource Monitoring
>>> + ID (RMID). Kernel assigns a new RMID when a group is created
>>> + depending on the available RMIDs. Multiple cores(or threads) or
>>> + processes can share a same RMID in a resctrl domain.
>>> +
>>> When control is enabled all CTRL_MON groups will also contain:
>>>
>>> "schemata":
>>> @@ -252,6 +260,13 @@ When control is enabled all CTRL_MON groups will
>>> also contain:
>>> file. On successful pseudo-locked region creation the mode will
>>> automatically change to "pseudo-locked".
>>>
>>> +"closid":
>>> + Reading this file shows the Class of Service (CLOS) id which acts
>>> + as a resource control tag on which the resources can be throttled.
>>> + Kernel assigns a new CLOSID a control group is created depending
>>> + on the available CLOSIDs. Multiple cores(or threads) or processes
>>> + can share a same CLOSID in a resctrl domain.
>>> +
>>> When monitoring is enabled all MON groups will also contain:
>>>
>>> "mon_data":
>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> index 0d71ed22cfa9..98b4798e5cae 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> @@ -769,6 +769,38 @@ static int rdtgroup_tasks_show(struct kernfs_open_file
>>> *of,
>>> return ret;
>>> }
>>>
>>> +static int rdtgroup_closid_show(struct kernfs_open_file *of,
>>> + struct seq_file *s, void *v)
>>> +{
>>> + struct rdtgroup *rdtgrp;
>>> + int ret = 0;
>>> +
>>> + rdtgrp = rdtgroup_kn_lock_live(of->kn);
>>> + if (rdtgrp)
>>> + seq_printf(s, "%u\n", rdtgrp->closid);
>>> + else
>>> + ret = -ENOENT;
>>> + rdtgroup_kn_unlock(of->kn);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int rdtgroup_rmid_show(struct kernfs_open_file *of,
>>> + struct seq_file *s, void *v)
>>> +{
>>> + struct rdtgroup *rdtgrp;
>>> + int ret = 0;
>>> +
>>> + rdtgrp = rdtgroup_kn_lock_live(of->kn);
>>> + if (rdtgrp)
>>> + seq_printf(s, "%u\n", rdtgrp->mon.rmid);
>>> + else
>>> + ret = -ENOENT;
>>> + rdtgroup_kn_unlock(of->kn);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> #ifdef CONFIG_PROC_CPU_RESCTRL
>>>
>>> /*
>>> @@ -1593,6 +1625,20 @@ static struct rftype res_common_files[] = {
>>> .seq_show = rdtgroup_size_show,
>>> .fflags = RF_CTRL_BASE,
>>> },
>>> + {
>>> + .name = "closid",
>>> + .mode = 0444,
>>> + .kf_ops = &rdtgroup_kf_single_ops,
>>> + .seq_show = rdtgroup_closid_show,
>>> + .fflags = RF_CTRL_BASE,
>>> + },
>>> + {
>>> + .name = "rmid",
>>> + .mode = 0444,
>>> + .kf_ops = &rdtgroup_kf_single_ops,
>>> + .seq_show = rdtgroup_rmid_show,
>>> + .fflags = RFTYPE_BASE,
>>> + },
>>>
>>> };
>>>
>>>
>> Thanks.
>>
>> -Fenghua
--
Thanks
Babu Moger
Powered by blists - more mailing lists