public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Tony Luck <tony.luck@intel.com>
To: babu.moger@amd.com
Cc: "Chatre, Reinette" <reinette.chatre@intel.com>,
	"james.morse@arm.com" <james.morse@arm.com>,
	Amit Singh Tomar <amitsinght@marvell.com>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	George Cherian <gcherian@marvell.com>,
	"robh@kernel.org" <robh@kernel.org>,
	"peternewman@google.com" <peternewman@google.com>,
	Drew Fustini <dfustini@baylibre.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: resctrl2 - status
Date: Fri, 8 Sep 2023 16:13:54 -0700	[thread overview]
Message-ID: <ZPuqsupe+BevodqO@agluck-desk3> (raw)
In-Reply-To: <09e2894e-eb2b-12a0-c4a2-5000b27bbded@amd.com>

On Fri, Sep 08, 2023 at 04:35:05PM -0500, Moger, Babu wrote:
> Hi Tony,
> 
> 
> On 9/8/2023 1:51 PM, Luck, Tony wrote:
> > > > Can you try this out on an AMD system. I think I covered most of the
> > > > existing AMD resctrl features, but I have no machine to test the code
> > > > on, so very likely there are bugs in these code paths.
> > > > 
> > > > I'd like to make any needed changes now, before I start breaking this
> > > > into reviewable bite-sized patches to avoid too much churn.
> > > I tried your latest code briefly on my system.  Unfortunately, I could
> > > not get it to work on my AMD system.
> > > 
> > > # git branch -a
> > >     next
> > > * resctrl2_v65
> > > # ]# uname -r
> > > 6.5.0+
> > > #lsmod |grep rdt
> > > rdt_show_ids           12288  0
> > > rdt_mbm_local_bytes    12288  0
> > > rdt_mbm_total_bytes    12288  0
> > > rdt_llc_occupancy      12288  0
> > > rdt_l3_cat             16384  0
> > > 
> > > # lsmod |grep mbe
> > > amd_mbec               16384  0
> > > 
> > > I could not get  rdt_l3_mba
> > > 
> > > # modprobe rdt_l3_mba
> > > modprobe: ERROR: could not insert 'rdt_l3_mba': No such device
> > > 
> > > I don't see any data for the default group either.
> > > 
> > > mount  -t resctrl resctrl /sys/fs/resctrl/
> > > 
> > > cd /sys/fs/resctrl/mon_data/mon_L3_00
> > > 
> > > cat mbm_summary
> > >        n/a      n/a /
> > Babu,
> > 
> > Thank a bunch for taking this for a quick spin. There's several bits of
> > good news there. Several modules automatically loaded as expected.
> > Nothing went "OOPS" and crashed the system.
> > 
> > Here’s the code that the rdt_l3_mba module runs that can cause failure
> > to load with "No such device"
> > 
> >          if (!boot_cpu_has(X86_FEATURE_RDT_A)) {
> >                  pr_debug("No RDT allocation support\n");
> >                  return -ENODEV;
> >          }
> 
> Shouldn't this be ?(or similar)
> 
> if (!rdt_cpu_has(X86_FEATURE_MBA))
>                 return false;

Yes. I should be using X86_FEATURE bits where they are available
rather than peeking directly at CPUID register bits.

> 
> >          mba_features = cpuid_ebx(0x10);
> > 
> >          if (!(mba_features & BIT(3))) {
> >                  pr_debug("No RDT MBA allocation\n");
> >                  return -ENODEV;
> >          }
> > 
> > I assume the first test must have succeeded (same code in rdt_l3_cat, and
> > that loaded OK). So must be the second. How does AMD enumerate MBA
> > support?
> > 
> > Less obvious what is the root cause of the mbm_summary file to fail to
> > show any data. rdt_mbm_local_bytes  and rdt_mbm_total_bytes  modules
> > loaded OK. So I'm looking for the right CPUID bits to detect memory bandwidth
> > monitoring.
> 
> I am still not sure if resctrl2 will address all the current gaps in
> resctrl1. We should probably list all issues on the table before we go that
> route.

Indeed yes! I don't want to have to do resctrl3 in a few years to
cover gaps that could have been addressed in resctrl2.

However, fixing resctrl gaps is only one of the motivations for
the rewrite. The bigger one is making life easier for all the
architectures sharing the common code to do what they need to
for their own quirks & differences without cluttering the
common code base, or worrying "did my change just break something
for another CPU architecture".

> One of the main issue for AMD is coupling of LLC domains.
> 
> For example, AMD hardware supports 16 CLOSids per LLC domain. But Linux
> design assumes that there are globally 16 total CLOSIDs for the whole
> systems. We can only create 16 CLOSID now irrespective of how many domains
> are there.
> 
> In reality, we should be able to create "16 x number of LLC domains" CLOSIDS
> in the systems.  This is more evident in AMD. But, same problem applies to
> Intel with multiple sockets.

I think this can be somewhat achieved already with a combination of
resctrl and cpusets (or some other way to set CPU affinity for tasks
to only run on CPUs within a specific domain (or set of domains).
That's why the schemata file allows setting different CBM masks
per domain.

Can you explain how you would use 64 domains on a system with 4 domains
and 16 CLOSID per domain?

> My 02 cents. Hope to discuss more in our upcoming meeting.
Agreed. This will be faster when we can talk instead of type :-)

-Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-09-08 23:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24 18:10 resctrl2 - status Luck, Tony
2023-08-25 17:47 ` Reinette Chatre
2023-08-25 18:09   ` Luck, Tony
2023-08-25 18:58     ` Reinette Chatre
2023-08-25 19:44       ` Luck, Tony
2023-08-25 20:20         ` Reinette Chatre
2023-08-25 20:54           ` Tony Luck
2023-08-25 23:08             ` Reinette Chatre
2023-08-26  1:11               ` Tony Luck
2023-08-28 14:50                 ` Reinette Chatre
2023-09-06 18:21                   ` Tony Luck
2023-09-08 18:08                     ` Moger, Babu
2023-09-08 18:51                       ` Luck, Tony
2023-09-08 21:35                         ` Moger, Babu
2023-09-08 23:13                           ` Tony Luck [this message]
2023-09-15 17:55                             ` Drew Fustini
2023-09-18 10:44                               ` Jonathan Cameron
2023-09-28  8:47                                 ` Peter Newman
2023-09-28 14:47                                   ` Luck, Tony
2023-09-29  9:38                                     ` Jonathan Cameron
2023-09-29 14:49                                   ` Drew Fustini
2023-09-15 17:16                     ` James Morse
2023-09-15 20:38                       ` Tony Luck
2023-09-21  0:21                         ` Tony Luck
2023-09-19 12:53                     ` Peter Newman
2023-09-19 16:40                       ` Tony Luck
2023-08-29 10:23           ` Jonathan Cameron
2023-08-29 17:18             ` [EXT] " Amit Singh Tomar
2023-08-30 10:47               ` Jonathan Cameron
2023-09-15 17:16                 ` James Morse

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=ZPuqsupe+BevodqO@agluck-desk3 \
    --to=tony.luck@intel.com \
    --cc=amitsinght@marvell.com \
    --cc=babu.moger@amd.com \
    --cc=dfustini@baylibre.com \
    --cc=fenghua.yu@intel.com \
    --cc=gcherian@marvell.com \
    --cc=james.morse@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peternewman@google.com \
    --cc=reinette.chatre@intel.com \
    --cc=robh@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