[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z64xNm7GrXuVj3gv@e133380.arm.com>
Date: Thu, 13 Feb 2025 17:51:50 +0000
From: Dave Martin <Dave.Martin@....com>
To: "Moger, Babu" <babu.moger@....com>
Cc: Peter Newman <peternewman@...gle.com>, corbet@....net,
reinette.chatre@...el.com, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, tony.luck@...el.com,
fenghua.yu@...el.com, x86@...nel.org, hpa@...or.com,
paulmck@...nel.org, akpm@...ux-foundation.org, thuth@...hat.com,
rostedt@...dmis.org, xiongwei.song@...driver.com,
pawan.kumar.gupta@...ux.intel.com, daniel.sneddon@...ux.intel.com,
jpoimboe@...nel.org, perry.yuan@....com, sandipan.das@....com,
kai.huang@...el.com, xiaoyao.li@...el.com, seanjc@...gle.com,
xin3.li@...el.com, andrew.cooper3@...rix.com, ebiggers@...gle.com,
mario.limonciello@....com, james.morse@....com,
tan.shaopeng@...itsu.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, maciej.wieczor-retman@...el.com,
eranian@...gle.com
Subject: Re: [PATCH v11 00/23] x86/resctrl : Support AMD Assignable Bandwidth
Monitoring Counters (ABMC)
On Mon, Feb 03, 2025 at 02:49:27PM -0600, Moger, Babu wrote:
> Hi Peter,
>
> On 2/3/25 08:54, Peter Newman wrote:
[...]
> >> # Linux Implementation
> >>
> >> Create a generic interface aimed to support user space assignment
> >> of scarce counters used for monitoring. First usage of interface
> >> is by ABMC with option to expand usage to "soft-ABMC" and MPAM
> >> counters in future.
> >
> > As a reminder of the work related to this, please take a look at the
> > thread where Reinette proposed a "shared counters" mode in
> > mbm_assign_control[1]. I am currently working to demonstrate that this
> > combined with the mbm_*_bytes_per_second events discussed earlier in
> > the same thread will address my users' concerns about the overhead of
> > reading a large number of MBM counters, resulting from a maximal
> > number of monitoring groups whose jobs are not isolated to any L3
> > monitoring domain.
> >
> > ABMC will add to the number of registers which need to be programmed
> > in each domain, so I will need to demonstrate that ABMC combined with
> > these additional features addresses their performance concerns and
> > that the resulting interface is user-friendly enough that they will
> > not need a detailed understanding of the implementation to avoid an
> > unacceptable performance degradation (i.e., needing to understand what
> > conditions will increase the number of IPIs required).
> >
> > If all goes well, soft-ABMC will try to extend this usage model to the
> > existing, pre-ABMC, AMD platforms I support.
> >
> > Thanks,
> > -Peter
> >
> > [1] https://lore.kernel.org/lkml/7ee63634-3b55-4427-8283-8e3d38105f41@intel.com/
> >
>
> Thanks for the heads-up. I understand what's going on and have an idea of
> the plan. Please keep us updated on the progress. Also, if any changes are
> needed in this series to meet your requirements, feel free to share your
> feedback.
Playing devil's advocate, I wonder whether there is a point beyond
which it would be better to have an interface to hand over some of the
counters to perf?
The logic for round-robin scheduling of events onto counters, dealing
with overflows etc. has already been invented over there, and it's
fiddly to get right. Ideally resctrl wouldn't have its own special
implementation of that kind of stuff.
(Said my someone who has never tried to hack up an uncore event source
in perf.)
Cheers
---Dave
Powered by blists - more mailing lists