Documentation/filesystems/resctrl.rst | 22 +++++++++++----- arch/x86/kernel/cpu/resctrl/monitor.c | 1 + fs/resctrl/internal.h | 2 ++ fs/resctrl/monitor.c | 30 ++++++++++++++++------ fs/resctrl/rdtgroup.c | 36 ++++++++++++++++++--------- include/linux/resctrl.h | 18 ++++++++------ 6 files changed, 77 insertions(+), 32 deletions(-)
Essentially a resend of v6, just adding a missing commit message separator, ---,
in the first commit. All patches now have Reinette's Reviewed-by tag, thanks!
Cover letter from v6:
No functional changes from v5. Just comment and commit message changes based on
review comments. Changelogs in patches.
Description from a previous version's cover letter:
A little bit of preparatory work to get ready for MPAM counter
assignment. Resctrl gained support last year for counter assignment for AMD
machines supporting ABMC. Tighten a few things up, that weren't needed for
AMD, so that the MPAM driver can emulate ABMC and hence support counter
assignment.
Based on v7.1-rc2
v1:
https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/
v2:
https://lore.kernel.org/lkml/20260313174524.3482767-1-ben.horgan@arm.com/
v3:
https://lore.kernel.org/lkml/20260319162225.378485-1-ben.horgan@arm.com/
v4:
https://lore.kernel.org/lkml/20260326172551.1553871-1-ben.horgan@arm.com/
v5:
https://lore.kernel.org/lkml/20260428130422.2287302-1-ben.horgan@arm.com/
v6:
https://lore.kernel.org/lkml/20260505155741.3591201-1-ben.horgan@arm.com/
Ben Horgan (7):
fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs()
x86,fs/resctrl: Create 'event_filter' files read only if they're not
configurable
fs/resctrl: Disallow the software controller when MBM counters are
assignable
fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed'
fs/resctrl: Continue counter allocation after failure
fs/resctrl: Document that automatic counter assignment is best effort
fs/resctrl: Document tasks file behaviour for task id 0 and idle tasks
Documentation/filesystems/resctrl.rst | 22 +++++++++++-----
arch/x86/kernel/cpu/resctrl/monitor.c | 1 +
fs/resctrl/internal.h | 2 ++
fs/resctrl/monitor.c | 30 ++++++++++++++++------
fs/resctrl/rdtgroup.c | 36 ++++++++++++++++++---------
include/linux/resctrl.h | 18 ++++++++------
6 files changed, 77 insertions(+), 32 deletions(-)
--
2.43.0
Hi Ben, The patches look good overall. Just one small note: I was testing v6 and noticed that v7 has already been posted. It would be helpful to leave a few days between versions unless you’re trying to make the merge window. Tested-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Babu Moger <babu.moger@amd.com> Thanks Babu On 5/6/2026 3:28 AM, Ben Horgan wrote: > Essentially a resend of v6, just adding a missing commit message separator, ---, > in the first commit. All patches now have Reinette's Reviewed-by tag, thanks! > > Cover letter from v6: > > No functional changes from v5. Just comment and commit message changes based on > review comments. Changelogs in patches. > > Description from a previous version's cover letter: > > A little bit of preparatory work to get ready for MPAM counter > assignment. Resctrl gained support last year for counter assignment for AMD > machines supporting ABMC. Tighten a few things up, that weren't needed for > AMD, so that the MPAM driver can emulate ABMC and hence support counter > assignment. > > Based on v7.1-rc2 > > v1: > https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/ > v2: > https://lore.kernel.org/lkml/20260313174524.3482767-1-ben.horgan@arm.com/ > v3: > https://lore.kernel.org/lkml/20260319162225.378485-1-ben.horgan@arm.com/ > v4: > https://lore.kernel.org/lkml/20260326172551.1553871-1-ben.horgan@arm.com/ > v5: > https://lore.kernel.org/lkml/20260428130422.2287302-1-ben.horgan@arm.com/ > v6: > https://lore.kernel.org/lkml/20260505155741.3591201-1-ben.horgan@arm.com/ > > Ben Horgan (7): > fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs() > x86,fs/resctrl: Create 'event_filter' files read only if they're not > configurable > fs/resctrl: Disallow the software controller when MBM counters are > assignable > fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed' > fs/resctrl: Continue counter allocation after failure > fs/resctrl: Document that automatic counter assignment is best effort > fs/resctrl: Document tasks file behaviour for task id 0 and idle tasks > > Documentation/filesystems/resctrl.rst | 22 +++++++++++----- > arch/x86/kernel/cpu/resctrl/monitor.c | 1 + > fs/resctrl/internal.h | 2 ++ > fs/resctrl/monitor.c | 30 ++++++++++++++++------ > fs/resctrl/rdtgroup.c | 36 ++++++++++++++++++--------- > include/linux/resctrl.h | 18 ++++++++------ > 6 files changed, 77 insertions(+), 32 deletions(-) >
On Wed, May 06, 2026 at 10:01:35AM -0500, Moger, Babu wrote:
> The patches look good overall. Just one small note: I was testing v6 and
> noticed that v7 has already been posted. It would be helpful to leave a few
> days between versions unless you’re trying to make the merge window.
Not even then. There's always the next merge window.
People need to get rid of this "let's rush half-baked shit in" thinking just
because the merge window is approaching. When it is approaching and your
patches have not been queued yet, then they should be postponed for the next
one.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi Boris and Babu, On 5/6/26 8:28 AM, Borislav Petkov wrote: > On Wed, May 06, 2026 at 10:01:35AM -0500, Moger, Babu wrote: >> The patches look good overall. Just one small note: I was testing v6 and >> noticed that v7 has already been posted. It would be helpful to leave a few >> days between versions unless you’re trying to make the merge window. > > Not even then. There's always the next merge window. > > People need to get rid of this "let's rush half-baked shit in" thinking just > because the merge window is approaching. When it is approaching and your > patches have not been queued yet, then they should be postponed for the next > one. > Ben is not rushing this work and has indeed been patiently addressing feedback. I considered this series to indeed be close to ready during the previous cycle but instead of rushing the polishing was left for this cycle. v7 closely followed v6 since we felt v6 was ready for inclusion but contained an unfortunate typo (missing a "---" in changelog). v7 was thus submitted shortly to ensure we pass a clean series to x86 maintainers for consideration. This is an instance where a brand new reviewer appears to a series after all patches have RB tag. I welcome and appreciate all reviews and it would be great to see more such collaboration to general resctrl and earlier in review cycles. In this case I do not believe this criticism about this work being half-baked and rushed is justified. Reinette
On Wed, May 06, 2026 at 08:58:07AM -0700, Reinette Chatre wrote:
> Ben is not rushing this work and has indeed been patiently addressing feedback.
> I considered this series to indeed be close to ready during the previous
> cycle but instead of rushing the polishing was left for this cycle.
>
> v7 closely followed v6 since we felt v6 was ready for inclusion but contained
> an unfortunate typo (missing a "---" in changelog). v7 was thus submitted shortly to
> ensure we pass a clean series to x86 maintainers for consideration.
Yap, I saw all that.
> This is an instance where a brand new reviewer appears to a series after all patches have
> RB tag. I welcome and appreciate all reviews and it would be great to see more such
> collaboration to general resctrl and earlier in review cycles. In this case I do not
> believe this criticism about this work being half-baked and rushed is justified.
I think you're misunderstanding me. My response was to Babu in an attempt to
correct his thinking that somehow patches should be rushed before a merge
window.
People tend to do that in front of merge windows and I'm replying to that
sentiment in the hope that as many people as possible read that and understand
that rushing patches never works and is never good.
It didn't have anything to do with Ben's patchset - it *just* happened to be
on that thread only.
As a matter of fact, I started applying his v7 but was waiting for Sashiko to
finish reviewing it.
I hope this makes the whole thing more clear.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Hi Boris, On 5/6/26 9:56 AM, Borislav Petkov wrote: > On Wed, May 06, 2026 at 08:58:07AM -0700, Reinette Chatre wrote: >> Ben is not rushing this work and has indeed been patiently addressing feedback. >> I considered this series to indeed be close to ready during the previous >> cycle but instead of rushing the polishing was left for this cycle. >> >> v7 closely followed v6 since we felt v6 was ready for inclusion but contained >> an unfortunate typo (missing a "---" in changelog). v7 was thus submitted shortly to >> ensure we pass a clean series to x86 maintainers for consideration. > > Yap, I saw all that. > >> This is an instance where a brand new reviewer appears to a series after all patches have >> RB tag. I welcome and appreciate all reviews and it would be great to see more such >> collaboration to general resctrl and earlier in review cycles. In this case I do not >> believe this criticism about this work being half-baked and rushed is justified. > > I think you're misunderstanding me. My response was to Babu in an attempt to > correct his thinking that somehow patches should be rushed before a merge > window. I did misunderstand. My apologies. > > People tend to do that in front of merge windows and I'm replying to that > sentiment in the hope that as many people as possible read that and understand > that rushing patches never works and is never good. ack. > > It didn't have anything to do with Ben's patchset - it *just* happened to be > on that thread only. > > As a matter of fact, I started applying his v7 but was waiting for Sashiko to > finish reviewing it. Thank you very much for considering this series. > > I hope this makes the whole thing more clear. It does. Thank you very much. Reinette
On Wed, May 06, 2026 at 10:06:34AM -0700, Reinette Chatre wrote:
> I did misunderstand. My apologies.
Nothing to apologize - all good.
:-)
Thanks!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On 5/6/26 16:01, Moger, Babu wrote: > Hi Ben, > > The patches look good overall. Just one small note: I was testing v6 and noticed that v7 has already been posted. It > would be helpful to leave a few days between versions unless you’re trying to make the merge window. > > Tested-by: Babu Moger <babu.moger@amd.com> > Reviewed-by: Babu Moger <babu.moger@amd.com> Thanks Babu :) > > Thanks > Babu > > On 5/6/2026 3:28 AM, Ben Horgan wrote: >> Essentially a resend of v6, just adding a missing commit message separator, ---, >> in the first commit. All patches now have Reinette's Reviewed-by tag, thanks! >> >> Cover letter from v6: >> >> No functional changes from v5. Just comment and commit message changes based on >> review comments. Changelogs in patches. >> >> Description from a previous version's cover letter: >> >> A little bit of preparatory work to get ready for MPAM counter >> assignment. Resctrl gained support last year for counter assignment for AMD >> machines supporting ABMC. Tighten a few things up, that weren't needed for >> AMD, so that the MPAM driver can emulate ABMC and hence support counter >> assignment. >> >> Based on v7.1-rc2 >> >> v1: >> https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/ >> v2: >> https://lore.kernel.org/lkml/20260313174524.3482767-1-ben.horgan@arm.com/ >> v3: >> https://lore.kernel.org/lkml/20260319162225.378485-1-ben.horgan@arm.com/ >> v4: >> https://lore.kernel.org/lkml/20260326172551.1553871-1-ben.horgan@arm.com/ >> v5: >> https://lore.kernel.org/lkml/20260428130422.2287302-1-ben.horgan@arm.com/ >> v6: >> https://lore.kernel.org/lkml/20260505155741.3591201-1-ben.horgan@arm.com/ >> >> Ben Horgan (7): >> fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs() >> x86,fs/resctrl: Create 'event_filter' files read only if they're not >> configurable >> fs/resctrl: Disallow the software controller when MBM counters are >> assignable >> fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed' >> fs/resctrl: Continue counter allocation after failure >> fs/resctrl: Document that automatic counter assignment is best effort >> fs/resctrl: Document tasks file behaviour for task id 0 and idle tasks >> >> Documentation/filesystems/resctrl.rst | 22 +++++++++++----- >> arch/x86/kernel/cpu/resctrl/monitor.c | 1 + >> fs/resctrl/internal.h | 2 ++ >> fs/resctrl/monitor.c | 30 ++++++++++++++++------ >> fs/resctrl/rdtgroup.c | 36 ++++++++++++++++++--------- >> include/linux/resctrl.h | 18 ++++++++------ >> 6 files changed, 77 insertions(+), 32 deletions(-) >> >
© 2016 - 2026 Red Hat, Inc.