From: Babu Moger <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
James Morse <james.morse@arm.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
H Peter Anvin <hpa@zytor.com>
Subject: RE: [PATCH v2 09/10] x86/resctrl: Add arch_has_sparse_bitmaps to explain AMD/Intel CAT difference
Date: Wed, 13 May 2020 15:03:57 -0500 [thread overview]
Message-ID: <980a693a-b823-96e1-9b4f-d7bbf4f09714@amd.com> (raw)
In-Reply-To: <8383ddd9-5849-d948-c391-aeb0cc927423@intel.com>
> -----Original Message-----
> From: Reinette Chatre <reinette.chatre@intel.com>
> Sent: Monday, May 11, 2020 1:15 PM
> To: James Morse <james.morse@arm.com>; x86@kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Fenghua Yu <fenghua.yu@intel.com>; Thomas Gleixner
> <tglx@linutronix.de>; Ingo Molnar <mingo@redhat.com>; Borislav Petkov
> <bp@alien8.de>; H Peter Anvin <hpa@zytor.com>; Moger, Babu
> <Babu.Moger@amd.com>
> Subject: Re: [PATCH v2 09/10] x86/resctrl: Add arch_has_sparse_bitmaps to
> explain AMD/Intel CAT difference
>
> Hi James,
>
> On 4/30/2020 10:03 AM, James Morse wrote:
> > Intel expects the cache bitmap provided by user-space to have on a
> > single span of 1s, whereas AMD can support bitmaps like 0xf00f.
> > Arm's MPAM support also allows sparse bitmaps.
> >
> > To move resctrl out to /fs/ we need to explain platform differences
> > like this. Add a resource property arch_has_sparse_bitmaps. Test this
> > around the 'non-consecutive' test in cbm_validate().
> >
> > Merging the validate calls causes AMD top gain the min_cbm_bits test
> > needed for Haswell, but as it always sets this value to 1, it will
> > never match.
> >
> > CC: Babu Moger <Babu.Moger@amd.com>
> > Signed-off-by: James Morse <james.morse@arm.com>
> > Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
>
> The Intel bits do indeed look good to me but we should check the AMD
> portion ... I peeked at the AMD spec [1] and found "If an L3_MASK_n
> register is programmed with all 0’s, that COS will be prevented from
> allocating any lines in the L3 cache" ... so AMD does allow bitmasks of
> all 0's (Intel does not).
>
> Does MPAM also allow all 0's? Perhaps "arch_has_sparse_bitmaps" can be
> used to indicate that also?
That is right. AMD allows L3 mask be all 0s. I will be great if this
property can be indicated it here. Thanks
next prev parent reply other threads:[~2020-05-13 20:04 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 17:03 [PATCH v2 00/10] x86/resctrl: Misc cleanup James Morse
2020-04-30 17:03 ` [PATCH v2 01/10] x86/resctrl: Nothing uses struct mbm_state chunks_bw James Morse
2020-04-30 17:03 ` [PATCH v2 02/10] x86/resctrl: Remove max_delay James Morse
2020-04-30 17:03 ` [PATCH v2 03/10] x86/resctrl: Fix stale comment James Morse
2020-04-30 17:03 ` [PATCH v2 04/10] x86/resctrl: use container_of() in delayed_work handlers James Morse
2020-04-30 17:03 ` [PATCH v2 05/10] x86/resctrl: Include pid.h James Morse
2020-04-30 17:03 ` [PATCH v2 06/10] x86/resctrl: Use is_closid_match() in more places James Morse
2020-05-11 20:42 ` Reinette Chatre
2020-04-30 17:03 ` [PATCH v2 07/10] x86/resctrl: Add arch_needs_linear to explain AMD/Intel MBA difference James Morse
2020-04-30 17:03 ` [PATCH v2 08/10] x86/resctrl: Merge AMD/Intel parse_bw() calls James Morse
2020-05-11 20:43 ` Reinette Chatre
2020-04-30 17:03 ` [PATCH v2 09/10] x86/resctrl: Add arch_has_sparse_bitmaps to explain AMD/Intel CAT difference James Morse
2020-05-11 18:14 ` Reinette Chatre
2020-05-13 20:03 ` Babu Moger [this message]
2020-05-15 18:21 ` James Morse
2020-05-15 19:15 ` Babu Moger
2020-04-30 17:04 ` [PATCH v2 10/10] cacheinfo: Move resctrl's get_cache_id() to the cacheinfo header file James Morse
2020-05-13 20:04 ` Babu Moger
2020-05-13 20:03 ` [PATCH v2 00/10] x86/resctrl: Misc cleanup Babu Moger
2020-05-14 15:29 ` Reinette Chatre
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=980a693a-b823-96e1-9b4f-d7bbf4f09714@amd.com \
--to=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=reinette.chatre@intel.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.