[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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