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: <20150224085909.GC17306@casper.infradead.org> Date: Tue, 24 Feb 2015 08:59:09 +0000 From: Thomas Graf <tgraf@...g.ch> To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, davem@...emloft.net Cc: alexei.starovoitov@...il.com, herbert@...dor.apana.org.au, kaber@...sh.net, ying.xue@...driver.com, netdev@...r.kernel.org, netfilter-devel@...r.kernel.org, josh@...htriplett.org Subject: Re: Ottawa and slow hash-table resize On 02/23/15 at 10:49am, Paul E. McKenney wrote: > Hello! > > Alexei mentioned that there was some excitement a couple of weeks ago in > Ottawa, something about the resizing taking forever when there were large > numbers of concurrent additions. One approach comes to mind: @Dave et al, Just want to make sure we have the same level of understanding of urgency for this. The only practical problem experienced so far is loading n*1M entries into an nft_hash set which takes 3s for 4M entries upon restore. A regular add is actually fine as it provides a hint and sizes the table accordingly. I agree that rhashtable should be improved to better handle many inserts on small tables but wanted to make sure whether anyone thinks this needs urgent fixing in 3.20 or whether we can take some time to fully understand all scenarios and experiment with ideas and then propose solutions for the next merge window. I also have the TCP hash tables on my radar while improving this. -- 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