Messages in this thread | | | Subject | Re: [PATCH V2 01/10] x86/CPU: Expose if cache is inclusive of lower level caches | From | Reinette Chatre <> | Date | Tue, 6 Aug 2019 11:13:22 -0700 |
| |
Hi Borislav,
On 8/6/2019 10:33 AM, Borislav Petkov wrote: > On Tue, Aug 06, 2019 at 09:55:56AM -0700, Reinette Chatre wrote: >> I am a bit cautious about this. When I started this work I initially >> added a helper function to resctrl that calls CPUID to determine if the >> cache is inclusive. At that time I became aware of a discussion >> motivating against scattered CPUID calls and motivating for one instance >> of CPUID information: >> http://lkml.kernel.org/r/alpine.DEB.2.21.1906162141301.1760@nanos.tec.linutronix.de > > Ah, there's that. That's still somewhat a work/discussion in progress > thing. Let me discuss it with tglx. > >> To answer your question about checking any cache: this seems to be > > I meant the CPUID on any CPU and thus any cache - i.e., all L3s on the > system should be inclusive and identical in that respect. Can't work > otherwise, I'd strongly presume.
This is my understanding, yes. While this patch supports knowing whether each L3 is inclusive or not, I expect this information to be the same for all L3 instances as will be supported by a single query in rdt_pseudo_lock_init(). This definitely is the case on the platforms we are enabling in this round.
>> 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. > > Hmm, so why are you enforcing the inclusivity now: > > + if (p->r->cache_level == 3 && > + !get_cache_inclusive(plr->cpu, p->r->cache_level)) { > + rdt_last_cmd_puts("L3 cache not inclusive\n"); > > but then will remove this requirement in the future? Why are we even > looking at cache inclusivity then and not make pseudo-locking work > regardless of that cache property?
Some platforms being enabled in this round have SKUs with inclusive cache and also SKUs with non-inclusive cache. The non-inclusive cache SKUs do not support cache pseudo-locking and cannot be made to support cache pseudo-locking with software changes. Needing to know if cache is inclusive or not will thus remain a requirement to distinguish between these different SKUs. Supporting cache pseudo-locking on platforms with non inclusive cache will require new hardware features. > Because if we're going to go and model this cache inclusivity property > properly in struct cpuinfo_x86 or struct cacheinfo or wherever, and do > that for all cache levels because apparently we're going to need that; > but then later it turns out we won't need it after all, why are we even > bothering? > > Or am I missing some aspect?
Reinette
| |