linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Thomas Graf <tgraf@suug.ch>, Herbert Xu <herbert@gondor.apana.org.au>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/5] Rhashtable: convert to bit-spin locks.
Date: Fri, 06 Jul 2018 17:22:30 +1000	[thread overview]
Message-ID: <153086169828.24852.10332573315056854948.stgit@noble> (raw)

bit-spinlocks are ideal for locking individual chains of a
hashtable as they do not take extra memory, and they share
a cachle line with the chain head which needs to be loaded (and often
written) anyway.

bit-spinlocks are not fair, but this is only a problem if contention
is likely.  Resizing hashtable are designed to avoid contention on
individual chains - when chains have more than a very few object, the
table is resized.

This is a resend of patches which have been previously posted.  The
only comment raised before concerned the need for lockdep support and
so the last patch was written and posted.
The only changes is that another occurrence of 'locks_mul' needed to
be removed.

Thanks,
NeilBrown

---

NeilBrown (5):
      rhashtable: use cmpxchg() in nested_table_alloc()
      rhashtable: don't hold lock on first table throughout insertion.
      rhashtable: allow rht_bucket_var to return NULL.
      rhashtable: use bit_spin_locks to protect hash bucket.
      rhashtable: add lockdep tracking to bucket bit-spin-locks.


 include/linux/rhashtable-types.h |    2 
 include/linux/rhashtable.h       |  216 +++++++++++++++++++++++++-------------
 ipc/util.c                       |    1 
 lib/rhashtable.c                 |  188 ++++++++++++++++-----------------
 net/bridge/br_fdb.c              |    1 
 net/bridge/br_vlan.c             |    1 
 net/bridge/br_vlan_tunnel.c      |    1 
 net/ipv4/ipmr.c                  |    1 
 net/ipv6/ip6mr.c                 |    1 
 net/netfilter/nf_tables_api.c    |    1 
 10 files changed, 233 insertions(+), 180 deletions(-)

--
Signature


             reply	other threads:[~2018-07-06  7:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06  7:22 NeilBrown [this message]
2018-07-06  7:22 ` [PATCH 2/5] rhashtable: don't hold lock on first table throughout insertion NeilBrown
2018-07-20  7:54   ` Herbert Xu
2018-07-20 14:41     ` Paul E. McKenney
2018-07-21  2:25       ` NeilBrown
2018-07-22 21:54         ` Paul E. McKenney
2018-07-22 23:13           ` NeilBrown
2018-07-23 20:56             ` Paul E. McKenney
2018-07-23 21:52               ` NeilBrown
2018-07-24 22:58                 ` Paul E. McKenney
2018-07-25  4:53                   ` NeilBrown
2018-07-25 15:22                     ` Paul E. McKenney
2018-07-27  1:04                       ` NeilBrown
2018-07-27  3:18                         ` Paul E. McKenney
2018-07-27 14:57                           ` Paul E. McKenney
2018-07-31  0:45                             ` NeilBrown
2018-07-31  4:14                               ` Paul E. McKenney
2018-07-31  5:04                                 ` NeilBrown
2018-07-31 14:44                                   ` Paul E. McKenney
2019-03-11 15:27                                     ` Paul E. McKenney
2019-03-11 21:50                                       ` NeilBrown
2019-03-11 22:10                                         ` Paul E. McKenney
2018-07-06  7:22 ` [PATCH 5/5] rhashtable: add lockdep tracking to bucket bit-spin-locks NeilBrown
2018-07-06  7:22 ` [PATCH 1/5] rhashtable: use cmpxchg() in nested_table_alloc() NeilBrown
2018-07-06  7:22 ` [PATCH 4/5] rhashtable: use bit_spin_locks to protect hash bucket NeilBrown
2018-07-06  7:22 ` [PATCH 3/5] rhashtable: allow rht_bucket_var to return NULL NeilBrown

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=153086169828.24852.10332573315056854948.stgit@noble \
    --to=neilb@suse.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --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).