Messages in this thread | | | Date | Tue, 6 Aug 2019 19:33:00 +0200 | From | Borislav Petkov <> | Subject | Re: [PATCH V2 01/10] x86/CPU: Expose if cache is inclusive of lower level caches |
| |
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.
> 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?
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?
Thx.
-- Regards/Gruss, Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
| |