[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8383ddd9-5849-d948-c391-aeb0cc927423@intel.com>
Date: Mon, 11 May 2020 11:14:57 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: James Morse <james.morse@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Cc: Fenghua Yu <fenghua.yu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
Babu Moger <Babu.Moger@....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@....com>
> Signed-off-by: James Morse <james.morse@....com>
> Reviewed-by: Reinette Chatre <reinette.chatre@...el.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?
Reinette
[1] https://developer.amd.com/wp-content/resources/56375.pdf
Powered by blists - more mailing lists