From: josh@joshtriplett.org
To: David Miller <davem@davemloft.net>
Cc: tgraf@suug.ch, kaber@trash.net, paulmck@linux.vnet.ibm.com,
alexei.starovoitov@gmail.com, herbert@gondor.apana.org.au,
ying.xue@windriver.com, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org
Subject: Re: Ottawa and slow hash-table resize
Date: Tue, 24 Feb 2015 10:45:02 -0800 [thread overview]
Message-ID: <20150224184502.GB10713@cloud> (raw)
In-Reply-To: <20150224.132603.842251066562193899.davem@davemloft.net>
On Tue, Feb 24, 2015 at 01:26:03PM -0500, David Miller wrote:
> From: Thomas Graf <tgraf@suug.ch>
> Date: Tue, 24 Feb 2015 17:50:14 +0000
>
> > On 02/24/15 at 12:09pm, David Miller wrote:
> >> Thinking about this, if inserts occur during a pending resize, if the
> >> nelems of the table has exceeded even the grow threshold for the new
> >> table, it makes no sense to allow these async inserts as they are
> >> going to make the resize take longer and prolong the pain.
> >
> > Let's say we start with an initial table size of 16K (we can make
> > this system memory depenend) and we grow by 8x. New inserts go
> > into the new table immediately so as soon as we have 12K entries
> > we'll grow right to 128K buckets. As we grow above 75K we'll start
> > growing to 1024K buckets. New entries already go to the 1024K
> > buckets at this point given that the first grow cycle should be
> > fast. The 2nd grow cycle would take an est 6 RCU grace periods.
> > This would also still give us a max of 8K bucket locks which
> > should be good enough as well.
>
> Actually, first of all, let's not start with larger tables.
>
> The network namespace folks showed clearly that hash tables
> are detrimental to per-ns memory costs. So they definitely
> want us to start with extremely small tables.
Agreed; ideally, the initial table size would just use a single page for
the array of bucket heads, which would give 1024 buckets on 32-bit
systems or 512 on 64-bit systems. That's more than enough for many
client systems, and for many single-application network namespaces.
> But once we know something is actively used, sure, increase
> the table grow rate as a response to demand.
>
> So how feasible is it to grow by 4x, 8x, or other powers of
> two in one resize operation?
Quite feasible. Actually, any integer multiple works fine, though I
think a power of two makes sense. I'd suggest trying 4x with the same
workloads that had an issue at 2x, and seeing how that goes.
- Josh Triplett
next prev parent reply other threads:[~2015-02-24 18:45 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 18:49 Ottawa and slow hash-table resize Paul E. McKenney
2015-02-23 19:12 ` josh
2015-02-23 21:03 ` Thomas Graf
2015-02-23 21:52 ` Paul E. McKenney
2015-02-23 22:32 ` David Miller
2015-02-23 23:06 ` Paul E. McKenney
2015-02-24 8:37 ` Thomas Graf
2015-02-24 10:39 ` Patrick McHardy
2015-02-24 10:46 ` David Laight
2015-02-24 10:48 ` Patrick McHardy
2015-02-24 17:09 ` David Miller
2015-02-24 17:50 ` Thomas Graf
2015-02-24 18:26 ` David Miller
2015-02-24 18:45 ` josh [this message]
2015-02-24 22:34 ` Thomas Graf
2015-02-25 8:56 ` Herbert Xu
2015-02-25 17:38 ` Thomas Graf
2015-02-24 18:33 ` josh
2015-02-25 8:55 ` Herbert Xu
2015-02-25 17:38 ` Thomas Graf
2015-02-23 21:00 ` Thomas Graf
2015-02-23 22:35 ` Paul E. McKenney
2015-02-24 8:59 ` Thomas Graf
2015-02-24 9:38 ` Daniel Borkmann
2015-02-24 10:42 ` Patrick McHardy
2015-02-24 16:14 ` Josh Hunt
2015-02-24 16:25 ` Patrick McHardy
2015-02-24 16:57 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2015-02-23 22:17 Alexei Starovoitov
2015-02-23 22:34 ` David Miller
2015-02-23 22:37 ` Paul E. McKenney
2015-02-23 23:07 Alexei Starovoitov
2015-02-23 23:15 ` 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=20150224184502.GB10713@cloud \
--to=josh@joshtriplett.org \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tgraf@suug.ch \
--cc=ying.xue@windriver.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).