| 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: Thu, 27 Jun 2013 17:08:29 +0800 From: Daniel J Blueman <daniel@...ascale-asia.com> To: Eric Dumazet <eric.dumazet@...il.com> CC: Linux Kernel <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, Steffen Persvold <sp@...ascale.com> Subject: Re: 13GB dcache+inode cache hash tables On 25/06/2013 17:48, Eric Dumazet wrote: > On Tue, 2013-06-25 at 16:56 +0800, Daniel J Blueman wrote: >> As memory capacity increases, we see the dentry and inode cache hash >> tables grow to wild sizes [1], eg 13GB is consumed on a 4.5TB system. >> >> Perhaps a better approach adds a linear component to an exponent to give >> tuned scaling, given that spatial locality is an advantage in hash table >> and careful use of resources. >> >> The same approach would fit to other hash tables (mount-cache, TCP >> established, TCP bind, UDP, UDP-Lite, Dquot-cache) with different >> coefficients, so perhaps we could generalise. >> > > TCP hash table is limited to 512K slots, unless overridden. > TCP bind limited to 64K slots. > UDP limited to 64K slots. > >> If so what are reasonable reference points and assumptions? > > I do not know what you have in mind, please show us a patch ;) [...] Alright, I'll see what I can get together in the next week or so when I can fit it in. Dan -- Daniel J Blueman Principal Software Engineer, Numascale Asia -- 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