linux-kernel - Re: [PATCH v8 08/25] x86/resctrl: Introduce interface to display number of monitoring counters

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <23b5a3d2-91ac-4467-9db0-3de483cfacf9@amd.com>
Date: Mon, 14 Oct 2024 14:21:03 -0500
From: "Moger, Babu" <babu.moger@....com>
To: "Luck, Tony" <tony.luck@...el.com>,
 "Chatre, Reinette" <reinette.chatre@...el.com>
Cc: "corbet@....net" <corbet@....net>, "Yu, Fenghua" <fenghua.yu@...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>,
 "paulmck@...nel.org" <paulmck@...nel.org>,
 "rdunlap@...radead.org" <rdunlap@...radead.org>,
 "tj@...nel.org" <tj@...nel.org>, "peterz@...radead.org"
 <peterz@...radead.org>, "yanjiewtw@...il.com" <yanjiewtw@...il.com>,
 "kim.phillips@....com" <kim.phillips@....com>,
 "lukas.bulwahn@...il.com" <lukas.bulwahn@...il.com>,
 "seanjc@...gle.com" <seanjc@...gle.com>,
 "jmattson@...gle.com" <jmattson@...gle.com>,
 "leitao@...ian.org" <leitao@...ian.org>,
 "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
 "Joseph, Jithu" <jithu.joseph@...el.com>, "Huang, Kai"
 <kai.huang@...el.com>, "kan.liang@...ux.intel.com"
 <kan.liang@...ux.intel.com>,
 "daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "sandipan.das@....com" <sandipan.das@....com>,
 "ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
 "peternewman@...gle.com" <peternewman@...gle.com>,
 "Wieczor-Retman, Maciej" <maciej.wieczor-retman@...el.com>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "Eranian, Stephane" <eranian@...gle.com>,
 "james.morse@....com" <james.morse@....com>
Subject: Re: [PATCH v8 08/25] x86/resctrl: Introduce interface to display
 number of monitoring counters

Hi Tony,

On 10/14/24 12:49, Luck, Tony wrote:
>>>> I.e. the user who chose this simply gave up being able to
>>>> read total bandwidth on domain 1, but didn't get an extra
>>>> counter in exchange for this sacrifice. That doesn't seem
>>>> like a good deal.
>>>
>>> As Babu mentioned earlier, this seems equivalent to the existing
>>> CLOSid management. For example, if a user assigns only CPUs
>>> from one domain to a resource group, it does not free up the
>>> CLOSID to create a new resource group dedicated to other domain(s).
> 
> I hadn't considered the case where a user is assigning CPUs to resctrl
> groups instead of assigning tasks. With that context this makes sense
> to me now.  Thanks.
> 
> 
>> Thanks for the confirmation here.
>>
>> I was wondering if this works differently on Intel. I was trying to figure
>> out on 2 socket intel system if we can create two separate resctrl groups
>> sharing the same CLOSID (one group using CLOSID 1 on socket 0 and another
>> group CLOSID 1 socket 1). No. We cannot do that.
>>
>> Even though hardware supports separate allocation for each domain, resctrl
>> design does not support that.
> 
> So CLOSIDs and counters are blanket assigned across all domains. I understand
> that now.
> 
> Back to my question of why complicate code and resctrl files by providing a
> mechanism to enable event counters differently per-domain.
> 
> "0=tl;1=_" requires allocation of the same counters as "0=tl;1=tl" or
> "0=t;1=l"

Yes. That is correct.

> 
> What advantage does it have over skipping the per-domain list and
> just providing a single value for all domains? You clearly expect this
> will be a common user request since you implemented the "*" means
> apply to all domains.
> 

We started with a global assignment by applying assignment across all the
domains initially.

But we wanted give a generic approach which allows both the options(domain
specific assignment and global assignment with '*"). It is also matches
with other managements (RMID/CLOSID management) we are doing in resctrl
right now. Also, there is an extra IPI for each domain if user is only
interested in on domain.

Some of the discussions are here.
https://lore.kernel.org/lkml/f7dac996d87b4144e4c786178a7fd3d218eaebe8.1711674410.git.babu.moger@amd.com/#r

Thanks
Babu Moger