From: Babu Moger <babu.moger@amd.com>
To: Ben Horgan <ben.horgan@arm.com>,
tony.luck@intel.com, reinette.chatre@intel.com, bp@alien8.de
Cc: x86@kernel.org, Dave.Martin@arm.com, james.morse@arm.com,
corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org,
tglx@kernel.org, mingo@redhat.com, dave.hansen@linux.intel.com,
hpa@zytor.com, kas@kernel.org, rick.p.edgecombe@intel.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-coco@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v4 2/3] fs/resctrl: Assign counters to existing groups when enabling mbm_event
Date: Tue, 13 Oct 2026 11:51:56 -0500 [thread overview]
Message-ID: <171f92a3-fa2e-44fb-b0d1-1250c72e31d1@amd.com> (raw)
In-Reply-To: <f79c5f94-3c5e-4c64-9b6f-95f186e1bdd7@arm.com>
Hi Ben,
On 10/13/26 10:57, Ben Horgan wrote:
> Hi Babu,
>
> On 10/10/2026 00:44, Babu Moger wrote:
>> When the user switches counter assignment mode by writing "mbm_event" to
>> /sys/fs/resctrl/info/L3_MON/mbm_assign_mode, resctrl frees all assignable
>> counters, resets per-domain RMID state, and enables counter auto-assignment
>> exposed to user space as mbm_assign_on_mkdir.
>>
>> Even though counter auto-assignment is enabled, groups that already exist
>> at the time of the switch, including the default group created at mount,
>> are not assigned a counter. All MBM events read "Unassigned" until the user
>> assigns a counter by hand.
>>
>> Walk every existing CTRL_MON and its MON children after the reset and
>> assign counters to their MBM events. Enabling "mbm_event" now leaves the
>> same per-group state that auto-assignment would have produced. There may be
>> fewer available counters than MBM events across the existing groups; in
>> that case stop assignment when no counters remain. Events in the remaining
>> groups read "Unassigned", matching the behavior of creating a group when no
>> counters are available. Also revise the rdtgroup_assign_cntrs() function
>> comments to account for the new callers.
>>
>> Fixes: 8004ea01cf63 ("fs/resctrl: Introduce the interface to switch between monitor modes")
>> Reported-by: Sashiko <sashiko-bot@kernel.org>
>> Closes: https://sashiko.dev/#/patchset/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger%40amd.com
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> Cc: stable@vger.kernel.org
>> ---
>> v4: Changelog update (Reinette's input).
>> Function comment update for rdtgroup_assign_cntrs().
>>
>> v3: Changelog update.
>> Code comment cleanup.
>> Added Cc to stable.
>> Added Reported-by and Closes tags.
>>
>> v2: New patch.
>> This patch addresses the Sashiko comment about documentation issue where
>> counters are not assigned automatically when mode is switched to mbm_event.
>> https://sashiko.dev/#/patchset/8cb66e18e32e4087a9712c1e68ee6da614efe244.1784322818.git.babu.moger%40amd.com
>> In fact, it exposed a real issue. When switching to mbm_event mode, existing
>> monitoring groups should be assigned counters whenever counters are available.
>> This provides a smooth transition between modes and aligns the behavior with
>> the existing auto-assignment mechanism.
>
>
> Given the name of the option is 'mbm_assign_on_mkdir' I expected the auto assignment to only occur
> on the creation of ctrl groups or monitor groups. That's not my concern though. As you are now
> treating this as more of a general auto assignment should the assignment also be done when a resctrl
> domain is brought back online.
>
> For illustration on an MPAM model I see:
>
> /sys/fs/resctrl# cat mbm_L3_assignments
> mbm_total_bytes:2=e;3=e
>
> # offline one domain
> /sys/fs/resctrl# for i in $(seq 0 3); do echo 0 > /sys/devices/system/cpu/cpu$i/online; done
> /sys/fs/resctrl# cat mbm_L3_assignments
> mbm_total_bytes:3=e
>
> # bring the domain back online
> /sys/fs/resctrl# cat mbm_L3_assignments
> mbm_total_bytes:2=_;3=e # Would it be better, or worse, for auto-assignment to occur here?
>
Interesting.
We don't know the previous state. What if it looked like this before the
CPU was taken offline?
/sys/fs/resctrl# cat mbm_L3_assignments
mbm_total_bytes:2=_;3=e
In that case, forcing auto-assignment may not be the right thing to do.
Since we don't know the previous state, we can only speculate.
It may be best to leave this decision to the user.
Thanks,
Babu
next prev parent reply other threads:[~2026-10-13 16:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 23:44 [PATCH v4 0/3] x86,fs/resctrl: Keep default MBM mode at boot and fix ABMC programming Babu Moger
2026-10-09 23:44 ` [PATCH v4 1/3] x86/resctrl: Fix ABMC counter programming Babu Moger
2026-10-12 18:40 ` Reinette Chatre
2026-10-13 1:00 ` Moger, Babu
2026-10-09 23:44 ` [PATCH v4 2/3] fs/resctrl: Assign counters to existing groups when enabling mbm_event Babu Moger
2026-10-12 18:44 ` Reinette Chatre
2026-10-13 1:02 ` Moger, Babu
2026-10-13 2:16 ` Reinette Chatre
2026-10-13 13:33 ` Babu Moger
2026-10-13 15:57 ` Ben Horgan
2026-10-13 16:51 ` Babu Moger [this message]
2026-10-13 18:22 ` Reinette Chatre
2026-10-13 18:52 ` Babu Moger
2026-10-09 23:44 ` [PATCH v4 3/3] x86,fs/resctrl: Keep mbm_assign_mode in default mode at boot Babu Moger
2026-10-12 18:47 ` Reinette Chatre
2026-10-13 1:09 ` 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=171f92a3-fa2e-44fb-b0d1-1250c72e31d1@amd.com \
--to=babu.moger@amd.com \
--cc=Dave.Martin@arm.com \
--cc=ben.horgan@arm.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=kas@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
--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