| 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: <p738x1b95zm.fsf@bingen.suse.de> Date: Sat, 23 Feb 2008 14:06:53 +0100 From: Andi Kleen <andi@...stfloor.org> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, David Miller <davem@...emloft.net>, Arnaldo Carvalho de Melo <acme@...hat.com> Subject: Re: [RFC PATCH 8/8] Jhash in too big for inlining, move under lib/ Andrew Morton <akpm@...ux-foundation.org> writes: > > It should be possible to use a modular jhash.ko. The things which you > have identified as clients of the jhash library are usually loaded as modules. For very small functions like this own modules are quite expensive. First everything gets rounded up to at least one 4K page (or worse on architectures with larger pages). That just wastes some memory. But then since modules live in vmalloc space they also need an own TLB entry, which are notouriously scarce in the kernel because often user space wants to monopolize them all. So if you're unlucky and user space is thrashing the TLB just a single call to this hash function will be an own TLB miss and quite expensive. It would be better to just always link it in for this case. -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