From: David Laight <David.Laight@ACULAB.COM>
To: "'Thomas Graf'" <tgraf@suug.ch>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"netfilter-devel@vger.kernel.org"
<netfilter-devel@vger.kernel.org>,
"coreteam@netfilter.org" <coreteam@netfilter.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: RE: [PATCH net-next] rhashtable: Lower/upper bucket may map to same lock while shrinking
Date: Tue, 13 Jan 2015 15:00:54 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CAC6946@AcuExch.aculab.com> (raw)
In-Reply-To: <20150113112507.GH20387@casper.infradead.org>
From: Thomas Graf
...
> > Thought, could the shrunk table use the same locks as the lower half
> > of the old table?
>
> No. A new bucket table and thus a new set of locks is allocated when the
> table is shrunk or grown. We only have check for overlapping locks
> when holding multiple locks for the same table at the same time.
I was guessing that when locks are shared buckets k and 2^n+k use the
same lock.
Under those conditions if the 'grow' decided not to allocate extra
locks then it could save work by using exactly the same locks as the
old table.
Similarly 'shrink' could do the reverse.
It was only a thought.
David
next prev parent reply other threads:[~2015-01-13 15:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-12 23:22 [rhashtable] WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:301 __debug_object_init() Fengguang Wu
2015-01-12 23:58 ` [PATCH net-next] rhashtable: Lower/upper bucket may map to same lock while shrinking Thomas Graf
2015-01-13 5:25 ` David Miller
2015-01-13 9:49 ` David Laight
2015-01-13 11:25 ` 'Thomas Graf'
2015-01-13 15:00 ` David Laight [this message]
2015-01-13 15:06 ` David Laight
2015-01-13 15:56 ` 'Thomas Graf'
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=063D6719AE5E284EB5DD2968C1650D6D1CAC6946@AcuExch.aculab.com \
--to=david.laight@aculab.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@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
all inboxes | Powered by JetHome®