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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Apr 2012 12:45:09 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Alex Shi <alex.shi@...el.com>
Cc:	andi.kleen@...el.com, tim.c.chen@...ux.intel.com, jeremy@...p.org,
	chrisw@...s-sol.org, akataria@...are.com, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, rostedt@...dmis.org,
	fweisbec@...il.com, riel@...hat.com, luto@....edu, avi@...hat.com,
	len.brown@...el.com, paul.gortmaker@...driver.com,
	dhowells@...hat.com, fenghua.yu@...el.com, yinghai@...nel.org,
	cpw@....com, steiner@....com, linux-kernel@...r.kernel.org,
	yongjie.ren@...el.com
Subject: Re: [PATCH 1/3] x86/tlb_info: get last level TLB entry number of CPU

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/