[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18004821-577d-b0dd-62b8-13b6f9264e72@intel.com>
Date: Tue, 6 Aug 2019 13:22:22 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Borislav Petkov <bp@...en8.de>
Cc: tglx@...utronix.de, fenghua.yu@...el.com, tony.luck@...el.com,
kuo-lang.tseng@...el.com, mingo@...hat.com, hpa@...or.com,
x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 01/10] x86/CPU: Expose if cache is inclusive of lower
level caches
Hi Borislav,
On 8/6/2019 12:16 PM, Borislav Petkov wrote:
> On Tue, Aug 06, 2019 at 11:53:40AM -0700, Reinette Chatre wrote:
>> In get_prefetch_disable_bits() the platforms that support cache
>> pseudo-locking are hardcoded as part of configuring the hardware
>> prefetch disable bits to use.
>
> Ok, so there is already a way to check pseudo-locking support.
Correct. This check is per platform though.
> Now, why
> do we have to look at cache inclusivity too?
... because some platforms differ in which SKUs support cache
pseudo-locking. On these platforms only the SKUs with inclusive cache
support cache pseudo-locking, thus the additional check.
>
> Your 0/10 mail says:
>
> "Only systems with L3 inclusive cache is supported at this time because
> if the L3 cache is not inclusive then pseudo-locked memory within the L3
> cache would be evicted when migrated to L2."
>
> but then a couple of mails earlier you said:
>
> "... this seems to be different between L2 and L3. On the Atom systems
> where L2 pseudo-locking works well the L2 cache is not inclusive. We are
> also working on supporting cache pseudo-locking on L3 cache that is not
> inclusive."
>
> which leads me to still think that we don't really need L3 cache
> inclusivity and theoretically, you could do without it.
>
> Or are you saying that cache pseudo-locking on non-inclusive L3 is not
> supported yet so no need to enable it yet?
Correct. Hardware and software changes will be needed to support this.
Reinette
Powered by blists - more mailing lists