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: <87mx2l41hl.fsf@xmission.com> Date: Fri, 27 Jul 2012 09:23:18 -0700 From: ebiederm@...ssion.com (Eric W. Biederman) To: Eric Dumazet <eric.dumazet@...il.com> Cc: David Miller <davem@...emloft.net>, alexander.duyck@...il.com, netdev@...r.kernel.org Subject: Re: [PATCH 00/16] Remove the ipv4 routing cache Eric Dumazet <eric.dumazet@...il.com> writes: > On Fri, 2012-07-27 at 07:53 -0700, Eric W. Biederman wrote: >> Eric Dumazet <eric.dumazet@...il.com> writes: >> >> > Now IP route cache is removed, we should make sure fib structures >> > cant share cache lines with possibly often dirtied objects. >> > >> > On x86, kmalloc-96 cache can be source of such problems. >> > >> > Signed-off-by: Eric Dumazet <edumazet@...gle.com> >> >> >> > +static inline void *fib_zalloc(size_t size) >> > +{ >> > + /* We want to avoid possible false sharing */ >> > + return kzalloc(max_t(size_t, 128, size), GFP_KERNEL); >> >> Why the hard coded 128 here? >> >> It seems more portable and obvious to do >> return kzalloc(round_up(size, L1_CACHE_BYTES), GFP_KERNEL); >> > > Its not that obvious, because some machines have an apparent > L1_CACHE_BYTES of 64, but hardware prefetching to 128 bytes I am familiar. But does hardware prefetching make a difference if your object is less than 64 bytes? I don't believe only allocating 64 bytes will be a problem, as no one else well be dirtying your cache line. I suppose you could run into pathologies where your object is 3*64 bytes in size, but your expression doesn't handle that case either. > But using 2*L1_CACHE_BYTES as minimum allocation size might be overkill > on some arches with 256 bytes cache lines. The other alternative to guarantee very good cache behavior is to ensure you are allocating a power of two size up to some limit, perhaps page size. My point is the magic 128 likely requires an explicatory comment and I think the net result is you have encoded something fragile that is good for testing but that will in the fullness of time do strange things that will be easy to overlook. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists