| 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: Mon, 23 Mar 2009 20:19:25 -0700 From: Ravikiran G Thirumalai <kiran@...lex86.org> To: Eric Dumazet <dada1@...mosbay.com> Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>, shai@...lex86.org, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [rfc] [patch 1/2 ] Process private hash tables for private futexes On Mon, Mar 23, 2009 at 10:57:55PM +0100, Eric Dumazet wrote: >Ravikiran G Thirumalai a écrit : >> [...] >> Hmm! How about >> a) Reduce hash table size for private futex hash and increase hash table >> size for the global hash? >> >> OR, better, >> >> b) Since it is multiple spinlocks on the same cacheline which is a PITA >> here, how about keeping the global table, but just add a dereference >> to each hash slot, and interleave the adjacent hash buckets between >> nodes/cpus? So even without needing to lose out memory from padding, >> we avoid false sharing on cachelines due to unrelated futexes hashing >> onto adjacent hash buckets? >> > >Because of jhash(), futex slots are almost random. No need to try to interleave >them. Since you have a "cache line" of 4096 bytes, you need almost 4 pages >per cpu to avoid in a statistical way false sharing. How did you come up with that number? So there is no way adjacent cachelines will never ever be used in the global hash?? -- 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