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
| ||
|
Date: Sat, 11 Oct 2008 14:59:53 +1100 From: Nick Piggin <nickpiggin@...oo.com.au> To: Andi Kleen <andi@...stfloor.org> Cc: Dave Jones <davej@...hat.com>, x86@...nel.org, Linux Kernel <linux-kernel@...r.kernel.org> Subject: Re: Update cacheline size on X86_GENERIC On Friday 10 October 2008 21:22, Andi Kleen wrote: > Nick Piggin wrote: > >>> Anyway, GENERIC kernel should run well on all architectures, and while > >>> going too big causes slightly increased structures sometimes, going too > >>> small could result in horrible bouncing. > >> > >> Exactly. > >> > >> That is it costs one percent or so on TPC, but I think the fix > >> for that is just to analyze where the problem is and size those > >> data structures based on the runtime cache size. Some subsystems > >> like slab do this already. > > > > Costs 1% on TPC? Is that 128 byte aligning data structures on > > Core2, or 64 byte aligning them on P4 that costs the performance? > > The first. BTW it was a rough number from memory, in that ballpark. > Also the experiment was on older kernels, might be different now. > > The second would undoubtedly be much worse. OK. Well I don't have a really strong opinion on what to do... I guess there is a reasonable argument to not care about P4 so much in today's GENERIC kernel. If it is worth around 1% on tpc on a more modern architecture, that is a pretty big motivation to change it too... -- 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