| 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
| ||
|
Message-Id: <200612080537.11936.ak@suse.de> Date: Fri, 8 Dec 2006 05:37:11 +0100 From: Andi Kleen <ak@...e.de> To: "Chen, Kenneth W" <kenneth.w.chen@...el.com> Cc: "linux-kernel" <linux-kernel@...r.kernel.org> Subject: Re: [patch] speed up single bio_vec allocation On Friday 08 December 2006 05:23, Chen, Kenneth W wrote: > Andi Kleen wrote on Thursday, December 07, 2006 6:28 PM > > "Chen, Kenneth W" <kenneth.w.chen@...el.com> writes: > > > I tried to use cache_line_size() to find out the alignment of struct bio, but > > > stumbled on that it is a runtime function for x86_64. > > > > It's a single global variable access: > > > > #define cache_line_size() (boot_cpu_data.x86_cache_alignment) > > > > Or do you mean it caused cache misses? boot_cpu_data is cache aligned > > and practically read only, so there shouldn't be any false sharing at least. > > No, I was looking for a generic constant that describes cache line size. The same kernel binary runs on CPUs with different cache line sizes. For example P4 has 128 bytes, Core2 64 bytes. However there is a worst case alignment that is used for static alignments which is L1_CACHE_BYTES. It would be normally 128 bytes on a x86 kernel, unless it is especially compiled for a CPU with a smaller cache line size. -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/
Powered by blists - more mailing lists