linux-kernel - Re: [patch] tlb flush_data: replace per

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, 12 Jan 2009 22:57:02 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Frederik Deweerdt <frederik.deweerdt@...og.eu>
Cc:	mingo@...e.hu, andi@...stfloor.org, tglx@...utronix.de,
	hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: [patch] tlb flush_data: replace per_cpu with an array

On Mon, Jan 12, 2009 at 10:35:42PM +0100, Frederik Deweerdt wrote:
> Hi,
> 
> On x86_64 flush tlb data is stored in per_cpu variables. This is
> unnecessary because only the first NUM_INVALIDATE_TLB_VECTORS entries
> are accessed.
> This patch aims at making the code less confusing (there's nothing
> really "per_cpu") by using a plain array. It also would save some memory
> on most distros out there (Ubuntu x86_64 has NR_CPUS=64 by default).

Nope it doesn't save memory on most systems because per cpu is only allocated
based on the CPUs that are actually there. And if you have more than 8
cores you can likely afford a few bytes per CPU.

You would need to cache line pad each entry then, otherwise you risk
false sharing. That would make the array 1K on 128 bytes cache line 
system.  This means on small systems this would actually waste
much more memory.

per cpu avoids that problem completely.

-Andi

--
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/