From: Thomas Graf <tgraf@suug.ch>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Patrick McHardy <kaber@trash.net>,
Josh Triplett <josh@joshtriplett.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
netdev@vger.kernel.org
Subject: Re: [v2 PATCH 7/10] rhashtable: Disable automatic shrinking
Date: Mon, 23 Mar 2015 10:08:52 +0000 [thread overview]
Message-ID: <20150323100852.GG16023@casper.infradead.org> (raw)
In-Reply-To: <20150323094454.GA12683@gondor.apana.org.au>
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.
next prev parent reply other threads:[~2015-03-23 10:08 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-22 8:03 [v2 PATCH 0/10] rhashtable: Multiple rehashing Herbert Xu
2015-03-22 8:03 ` [v2 PATCH 1/10] rhashtable: Add barrier to ensure we see new tables in walker Herbert Xu
2015-03-22 10:47 ` Thomas Graf
2015-03-22 8:04 ` [v2 PATCH 2/10] rhashtable: Eliminate unnecessary branch in rht_key_hashfn Herbert Xu
2015-03-22 11:07 ` Thomas Graf
2015-03-22 8:04 ` [v2 PATCH 3/10] rhashtable: Allow hashfn to be unset Herbert Xu
2015-03-22 11:55 ` Thomas Graf
2015-03-22 12:04 ` Herbert Xu
2015-03-22 12:32 ` Thomas Graf
2015-03-22 21:12 ` Herbert Xu
2015-03-23 9:58 ` Thomas Graf
2015-03-23 10:18 ` Herbert Xu
2015-03-23 14:29 ` David Laight
2015-03-22 8:04 ` [v2 PATCH 4/10] netlink: Use default rhashtable hashfn Herbert Xu
2015-03-22 11:55 ` Thomas Graf
2015-03-23 1:18 ` Simon Horman
2015-03-23 12:56 ` Herbert Xu
2015-03-22 8:04 ` [v2 PATCH 5/10] tipc: " Herbert Xu
2015-03-22 11:56 ` Thomas Graf
2015-03-22 8:04 ` [v2 PATCH 6/10] netfilter: " Herbert Xu
2015-03-22 11:56 ` Thomas Graf
2015-03-23 11:32 ` Herbert Xu
2015-03-22 8:04 ` [v2 PATCH 7/10] rhashtable: Disable automatic shrinking Herbert Xu
2015-03-22 12:17 ` Thomas Graf
2015-03-22 13:06 ` Thomas Graf
2015-03-23 0:07 ` Herbert Xu
2015-03-23 8:37 ` Thomas Graf
2015-03-23 9:29 ` Herbert Xu
2015-03-23 9:43 ` Thomas Graf
2015-03-23 0:09 ` Herbert Xu
2015-03-23 8:33 ` Thomas Graf
2015-03-23 9:28 ` Herbert Xu
2015-03-23 9:36 ` Thomas Graf
2015-03-23 9:39 ` Herbert Xu
2015-03-23 9:44 ` Herbert Xu
2015-03-23 10:08 ` Thomas Graf [this message]
2015-03-23 10:19 ` Herbert Xu
2015-03-23 16:45 ` David Miller
2015-03-23 16:44 ` David Miller
2015-03-23 21:48 ` Herbert Xu
2015-03-23 22:13 ` Thomas Graf
2015-03-22 8:04 ` [v2 PATCH 8/10] rhashtable: Add multiple rehash support Herbert Xu
2015-03-22 8:04 ` [v2 PATCH 9/10] rhashtable: Allow GFP_ATOMIC bucket table allocation Herbert Xu
2015-03-22 8:04 ` [v2 PATCH 10/10] rhashtable: Add immediate rehash during insertion Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150323100852.GG16023@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=josh@joshtriplett.org \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).