Re: [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU

[Borislav Petkov <bp@amd64.org>]

On Mon, Apr 30, 2012 at 12:25:46PM +0800, Alex Shi wrote:
> >> +enum tlb_infos {
> >> +	ENTRIES,
> >> +	/* ASS_WAYS, */
> > 
> > We don't need associativity?
> 
> Detailed associative ways type(set,skewed etc) should effect the cache
> behavior, but I don't know the detailed associate type for each kind of
> CPU, and also don't know the detailed CPU hardware optimization for
> associative ways. (Some one said there is hardware hash to map memory
> into cache). But I don't know details, and can not do optimizing
> accordingly.
> and another reason is: according to this chart:
> http://en.wikipedia.org/wiki/File:Cache,missrate.png that from
> http://en.wikipedia.org/wiki/CPU_cache
> , seems we needn't care too much about the associative ways.

Yeah, we have the associativity in CPUID too but factoring in the exact
replacement policy here could probably be not worth it.

So the commented out ASS_WAYS above can be removed.

[..]

> > Also, there's cpuinfo_x86.x86_tlbsize which is L1 iTLB + L1 dTLB 4K
> > entries. The tlb sizes below could probably be integrated/cached there
> > too if this proves to bring some speedup.
>
> I have tried to fill the info into cpuinfo_x86 first, but got the info
> from there instead of 'read_mostly' area is hart performance.
> 
> BTW, I didn't see x86_tlbsize was printed under Intel's CPUs.

It should be in /proc/cpuinfo as "TLB size". But you're probably right,
having it in a __read_mostly section is probably better because a lot
less cross-CPU probes for that data would be needed.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551