From: "Moger, Babu" <bmoger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
babu.moger@amd.com, tony.luck@intel.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: corbet@lwn.net, x86@kernel.org, hpa@zytor.com,
akpm@linux-foundation.org, paulmck@kernel.org,
rostedt@goodmis.org, thuth@redhat.com, ardb@kernel.org,
gregkh@linuxfoundation.org, thomas.lendacky@amd.com,
mario.limonciello@amd.com, perry.yuan@amd.com, seanjc@google.com,
kai.huang@intel.com, xiaoyao.li@intel.com,
kan.liang@linux.intel.com, riel@surriel.com, xin3.li@intel.com,
xin@zytor.com, sohil.mehta@intel.com, ak@linux.intel.com,
ebiggers@google.com, andrew.cooper3@citrix.com,
gautham.shenoy@amd.com, Xiaojian.Du@amd.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
james.morse@arm.com, fenghuay@nvidia.com, peternewman@google.com
Subject: Re: [PATCH v4 0/8] Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE)
Date: Mon, 5 May 2025 17:29:39 -0500 [thread overview]
Message-ID: <1f6e891b-fcd9-48e5-bf85-7e30ec66374b@amd.com> (raw)
In-Reply-To: <c79d7c1c-e7a0-43bd-821a-947c910cd04d@intel.com>
Hi Reinette,
On 5/5/2025 4:13 PM, Reinette Chatre wrote:
> Hi Babu,
>
> On 5/5/25 12:54 PM, Moger, Babu wrote:
>> On 5/5/25 11:22, Reinette Chatre wrote:
>>> On 5/2/25 5:53 PM, Moger, Babu wrote:
>>>> On 5/2/2025 4:20 PM, Reinette Chatre wrote:
>>>>> On 4/21/25 3:43 PM, Babu Moger wrote:
>
> ...
>
>>>>>
>>>>> Then "bit_usage" will look like:
>>>>>
>>>>> # cat /sys/fs/resctrl/info/L3/bit_usage
>>>>> 0=HHHHXXXXSSSS0000
>>>>
>>>> It is confusing here. To make it clear we may have to print all the CLOSes in each domain.
>>>
>>> Could you please elaborate how this is confusing?
>>
>> # cat /sys/fs/resctrl/info/L3/bit_usage
>> 0=HHHHXXXXSSSS0000
>>
>> This may give the impression that the all CLOSes in all domains carries
>> this property, but in reality, it applies only to one CLOS(15) within each
>> domain.
>>
>> Example below....
>>
>
> ...
>
>> Here is the behaviour after these cahnges.
>>
>> === Before io_alloc enabled==============================
>>
>> #cd /sys/fs/resctrl/L3/
>> # cat io_alloc
>> disabled
>>
>> # cat shareable_bits
>> 0 (This is always 0 for AMD)
>>
>> # cat bit_usage
>> 0=SSSSSSSSSSSSSSSS;1=SSSSSSSSSSSSSSSS;2=SSSSSSSSSSSSSSSS;3=SSSSSSSSSSSSSSSS
>
> Please note that the "S" in above does not have anything to do with
> "shareable_bits" at this point. The "S" indicates that all L3 instances
> are currently used by software and that sharing is allowed.
>
> "bit_usage" gives insight to user space how all L3 instances are used.
>
> If at this point a new resource group is created and it has an "exclusive"
> allocation then "bit_usage" will change to reflect that. For example,
> you can try this on the system you are testing on:
>
> # echo 'L3:0=fff0;1=fff0;2=fff0;3=fff0' > /sys/fs/resctrl/schemata
> # mkdir /sys/fs/resctrl/g1
> # echo 'L3:0=f;1=f;2=f;3=f' > /sys/fs/resctrl/g1/schemata
> # echo 'exclusive' > /sys/fs/resctrl/g1/mode
>
> The above isolates a portion of all L3 instances for exclusive use by g1.
> After above changes:
> # cat /sys/fs/resctrl/info/L3/bit_usage
> 0=SSSSSSSSSSSSEEEE;1=SSSSSSSSSSSSEEEE;2=SSSSSSSSSSSSEEEE;3=SSSSSSSSSSSSEEEE
>
Yes. I see the same output.
> Note that there is no "closid" or resource group information but instead,
> "bit_usage" shows to user space how each cache instance is being used
> across all resource groups and hardware (IO) allocations.
Ok. Got it.
>
>>
>> ==== After io_alloc enabled=================================
>>
>> # echo 1 > io_alloc
>>
>> # cat io_alloc
>> enabled
>>
>> # cat io_alloc_cbm
>> L3:0=ffff;1=ffff;2=ffff;3=ffff
>>
>> #cat bit_usage
>> 0=XXXXXXXXXXXXXXXX;1=XXXXXXXXXXXXXXXX;2=XXXXXXXXXXXXXXXX;3=XXXXXXXXXXXXXXXX
>
> Looks accurate to me. It shows that both hardware and software can
> allocate into all portions of all caches.
>
>>
>> ==== After changing io_alloc_cbm ============================
>>
>> #echo "L3:0=ff00;1=ff00;2=ff00;3=ff00 > io_alloc_cbm
>>
>> # cat io_alloc_cbm
>> L3:0=ff00;1=ff00;2=ff00;3=ff00
>>
>> #cat bit_usage
>> 0=XXXXXXXXSSSSSSSS;1=XXXXXXXXSSSSSSSS;2=XXXXXXXXSSSSSSSS;3=XXXXXXXXSSSSSSSS
>
> Looks accurate to me.
>
>> =============================================================
>>
>> My concern here is, this may imply that the property is present across all
>> CLOSes in all the domains, while in fact, it only applies to a single
>> CLOS(15) within each domain.
>
> If a user wants a resource group specific view then the schemata should be used.
> "bit_usage" presents the view from the cache instance perspective and reflects
> how each L3 cache instance is being used at that moment in time. It helps
> system administrator answer the question "how are the caches used at the moment"?
> "bit_usage" does so by presenting a summary of all allocations across all resource
> groups and any hardware allocations that may exist. This file helps user space
> to understand how the cache is being used without needing to correlate the CBMs
> of all resource groups and IO allocations. For example, "bit_usage" is to be used
> by system administrator to ensure cache is used optimally (for example, there are
> no unused portions). Also, a user may be investigating a performance issue in
> a particular resource group and "bit_usage" will help with that to see if
> the tasks in that resource group may be competing with IO.
>
Ok, "bit_usage" is a summary across all the groups. That is a good
point. Thanks for the detailed explanation.
Will make those changes in next revision.
Thank you.
Babu
prev parent reply other threads:[~2025-05-05 22:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-21 22:43 Babu Moger
2025-04-21 22:43 ` [PATCH v4 1/8] x86/cpufeatures: Add support for L3 Smart Data Cache Injection Allocation Enforcement Babu Moger
2025-04-21 22:43 ` [PATCH v4 2/8] x86/resctrl: Add SDCIAE feature in the command line options Babu Moger
2025-04-21 22:43 ` [PATCH v4 3/8] x86/resctrl: Detect io_alloc feature Babu Moger
2025-04-21 22:43 ` [PATCH v4 4/8] x86/resctrl: Implement "io_alloc" enable/disable handlers Babu Moger
2025-04-21 22:43 ` [PATCH v4 5/8] x86/resctrl: Add user interface to enable/disable io_alloc feature Babu Moger
2025-04-21 22:43 ` [PATCH v4 6/8] x86/resctrl: Introduce interface to display io_alloc CBMs Babu Moger
2025-04-21 22:43 ` [PATCH v4 7/8] x86/resctrl: Modify rdt_parse_data to pass mode and CLOSID Babu Moger
2025-04-21 22:43 ` [PATCH v4 8/8] x86/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks Babu Moger
2025-05-02 21:20 ` [PATCH v4 0/8] Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Reinette Chatre
2025-05-03 0:53 ` Moger, Babu
2025-05-05 16:22 ` Reinette Chatre
2025-05-05 17:01 ` Luck, Tony
2025-05-05 17:14 ` Reinette Chatre
2025-05-05 17:27 ` Luck, Tony
2025-05-05 17:39 ` Reinette Chatre
2025-05-05 17:50 ` Luck, Tony
2025-05-05 19:54 ` Moger, Babu
2025-05-05 21:13 ` Reinette Chatre
2025-05-05 22:29 ` Moger, Babu [this message]
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=1f6e891b-fcd9-48e5-bf85-7e30ec66374b@amd.com \
--to=bmoger@amd.com \
--cc=Xiaojian.Du@amd.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=ardb@kernel.org \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=ebiggers@google.com \
--cc=fenghuay@nvidia.com \
--cc=gautham.shenoy@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=perry.yuan@amd.com \
--cc=peternewman@google.com \
--cc=reinette.chatre@intel.com \
--cc=riel@surriel.com \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.com \
--cc=sohil.mehta@intel.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=thuth@redhat.com \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
--cc=xin3.li@intel.com \
--cc=xin@zytor.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
all inboxes | Powered by JetHome®