linux-kernel - Re: [patch] speed up single bio

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 for Android: free password hash cracker in your pocket

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

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/