[lkml]   [2019]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/3] rhashtable: don't hold lock on first table throughout insertion.
On Fri, Mar 15, 2019 at 05:46:37PM +1100, NeilBrown wrote:
> From: NeilBrown <>
> Date: Mon, 25 Jun 2018 08:09:19 +1000
> Subject: [PATCH] rhashtable: don't hold lock on first table throughout
> insertion.
> rhashtable_try_insert() currently holds a lock on the bucket in
> the first table, while also locking buckets in subsequent tables.
> This is unnecessary and looks like a hold-over from some earlier
> version of the implementation.
> As insert and remove always lock a bucket in each table in turn, and
> as insert only inserts in the final table, there cannot be any races
> that are not covered by simply locking a bucket in each table in turn.
> When an insert call reaches that last table it can be sure that there
> is no matchinf entry in any other table as it has searched them all, and
> insertion never happens anywhere but in the last table. The fact that
> code tests for the existence of future_tbl while holding a lock on
> the relevant bucket ensures that two threads inserting the same key
> will make compatible decisions about which is the "last" table.
> This simplifies the code and allows the ->rehash field to be
> discarded.
> We still need a way to ensure that a dead bucket_table is never
> re-linked by rhashtable_walk_stop(). This can be achieved by calling
> call_rcu() inside the locked region, and checking with
> rcu_head_after_call_rcu() in rhashtable_walk_stop() to see if the
> bucket table is empty and dead.
> Signed-off-by: NeilBrown <>
> ---
> include/linux/rhashtable.h | 13 ------------
> lib/rhashtable.c | 52 ++++++++++++++--------------------------------
> 2 files changed, 16 insertions(+), 49 deletions(-)

Acked-by: Herbert Xu <>
Email: Herbert Xu <>
Home Page:
PGP Key:

 \ /
  Last update: 2019-03-20 06:41    [W:0.056 / U:4.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site