[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150323100852.GG16023@casper.infradead.org>
Date: Mon, 23 Mar 2015 10:08:52 +0000
From: Thomas Graf <tgraf@...g.ch>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>,
Patrick McHardy <kaber@...sh.net>,
Josh Triplett <josh@...htriplett.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
netdev@...r.kernel.org
Subject: Re: [v2 PATCH 7/10] rhashtable: Disable automatic shrinking
On 03/23/15 at 08:44pm, Herbert Xu wrote:
> On Mon, Mar 23, 2015 at 08:39:52PM +1100, Herbert Xu wrote:
> >
> > Because with multiple rehashing it's quite easy to convert your
> > hash table into a linked list by repeatedly growing and shrinking.
> >
> > Multiple rehashing simply cannot work unless you get rid of automatic
> > shrinking for the untrusted case.
>
> Actually what I could do is allow automatic shrinking when there
> are no outstanding rehashes. So maybe we could restore this feature
> after all.
OK. Maybe this patch should be posted in the context of enabling
multiple rehashes then. It is difficult to review without having
the full context. This correlation was not clear to me from the
commit message.
I have yet to understand the implications of multiple rehashes.
The idea of having to traverse N tables for each insert, removal
and lookup in a pressure situation is still frightening.
I would like to compare it with an exponential growing logic.
Eventually both approaches can be combined to limit the chain
length of rehashes.
--
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