From: Thomas Graf <tgraf@suug.ch>
To: josh@joshtriplett.org
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
alexei.starovoitov@gmail.com, herbert@gondor.apana.org.au,
kaber@trash.net, davem@davemloft.net, ying.xue@windriver.com,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: Ottawa and slow hash-table resize
Date: Mon, 23 Feb 2015 21:03:58 +0000 [thread overview]
Message-ID: <20150223210358.GB806@casper.infradead.org> (raw)
In-Reply-To: <20150223191201.GA4355@cloud>
On 02/23/15 at 11:12am, josh@joshtriplett.org wrote:
> In theory, resizes should only take the locks for the buckets they're
> currently unzipping, and adds should take those same locks. Neither one
> should take a whole-table lock, other than resize excluding concurrent
> resizes. Is that still insufficient?
Correct, this is what happens. The problem is basically that
if we insert from atomic context we cannot slow down inserts
and the table may not grow quickly enough.
> Yeah, the add/remove statistics used for tracking would need some
> special handling to avoid being a table-wide bottleneck.
Daniel is working on a patch to do per-cpu element counting
with a batched update cycle.
next prev parent reply other threads:[~2015-02-23 21:03 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 [this message]
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
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=20150223210358.GB806@casper.infradead.org \
--to=tgraf@suug.ch \
--cc=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=josh@joshtriplett.org \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--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).