From: Florian Westphal <fw@strlen.de>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
Thomas Graf <tgraf@suug.ch>,
netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] rhashtable: Add nested tables
Date: Tue, 7 Feb 2017 14:17:28 +0100 [thread overview]
Message-ID: <20170207131728.GA11584@breakpoint.cc> (raw)
In-Reply-To: <E1cb53h-0003qD-No@gondobar>
Herbert Xu <herbert@gondor.apana.org.au> wrote:
> This patch adds code that handles GFP_ATOMIC kmalloc failure on
> insertion. As we cannot use vmalloc, we solve it by making our
> hash table nested. That is, we allocate single pages at each level
> and reach our desired table size by nesting them.
>
> When a nested table is created, only a single page is allocated
> at the top-level. Lower levels are allocated on demand during
> insertion. Therefore for each insertion to succeed, only two
> (non-consecutive) pages are needed.
>
> After a nested table is created, a rehash will be scheduled in
> order to switch to a vmalloced table as soon as possible. Also,
> the rehash code will never rehash into a nested table. If we
> detect a nested table during a rehash, the rehash will be aborted
> and a new rehash will be scheduled.
Ok, but why?
It seems to add a whole lot of complexity...
What users can't handle the insert failure case until resize
has completed?
Would relaxing the max chain length (until rehash is done) be an
alternative?
next prev parent reply other threads:[~2017-02-07 13:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-07 12:38 [PATCH 0/3] rhashtable: Handle table allocation failure during insertion Herbert Xu
2017-02-07 12:39 ` [PATCH 1/3] gfs2: Use rhashtable walk interface in glock_hash_walk Herbert Xu
2017-02-07 12:39 ` [PATCH 2/3] tipc: Fix tipc_sk_reinit race conditions Herbert Xu
2017-02-10 10:53 ` Ying Xue
2017-02-07 12:39 ` [PATCH 3/3] rhashtable: Add nested tables Herbert Xu
2017-02-07 13:17 ` Florian Westphal [this message]
2017-02-07 13:29 ` Herbert Xu
2017-02-07 18:02 ` Florian Westphal
2017-02-08 1:09 ` Herbert Xu
2017-02-09 2:12 ` [lkp-robot] [rhashtable] 60be2ebf32: INFO:suspicious_RCU_usage kernel test robot
2017-02-08 18:26 ` [PATCH 0/3] rhashtable: Handle table allocation failure during insertion David Miller
2017-02-11 11:22 ` Herbert Xu
2017-02-11 11:24 ` [v2 PATCH " Herbert Xu
2017-02-11 11:26 ` [v2 PATCH 1/3] gfs2: Use rhashtable walk interface in glock_hash_walk Herbert Xu
2017-02-11 11:26 ` [v2 PATCH 2/3] tipc: Fix tipc_sk_reinit race conditions Herbert Xu
2017-02-11 11:26 ` [v2 PATCH 3/3] rhashtable: Add nested tables Herbert Xu
2017-02-14 3:18 ` [v2 PATCH 0/3] rhashtable: Handle table allocation failure during insertion David Miller
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=20170207131728.GA11584@breakpoint.cc \
--to=fw@strlen.de \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/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).