1. 11 Dec, 2017 1 commit
    • Tom Herbert's avatar
      rhashtable: Change rhashtable_walk_start to return void · 97a6ec4a
      Tom Herbert authored
      Most callers of rhashtable_walk_start don't care about a resize event
      which is indicated by a return value of -EAGAIN. So calls to
      rhashtable_walk_start are wrapped wih code to ignore -EAGAIN. Something
      like this is common:
             ret = rhashtable_walk_start(rhiter);
             if (ret && ret != -EAGAIN)
                     goto out;
      Since zero and -EAGAIN are the only possible return values from the
      function this check is pointless. The condition never evaluates to true.
      This patch changes rhashtable_walk_start to return void. This simplifies
      code for the callers that ignore -EAGAIN. For the few cases where the
      caller cares about the resize event, particularly where the table can be
      walked in mulitple parts for netlink or seq file dump, the function
      rhashtable_walk_start_check has been added that returns -EAGAIN on a
      resize event.
      Signed-off-by: default avatarTom Herbert <tom@quantonium.net>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  2. 22 Sep, 2017 1 commit
  3. 19 Sep, 2017 4 commits
  4. 25 Jul, 2017 1 commit
  5. 24 Jul, 2017 1 commit
    • Phil Sutter's avatar
      lib: test_rhashtable: fix for large entry counts · e859afe1
      Phil Sutter authored
      During concurrent access testing, threadfunc() concatenated thread ID
      and object index to create a unique key like so:
      | tdata->objs[i].value = (tdata->id << 16) | i;
      This breaks if a user passes an entries parameter of 64k or higher,
      since 'i' might use more than 16 bits then. Effectively, this will lead
      to duplicate keys in the table.
      Fix the problem by introducing a struct holding object and thread ID and
      using that as key instead of a single integer type field.
      Fixes: f4a3e90b ("rhashtable-test: extend to test concurrency")
      Reported by: Manuel Messner <mm@skelett.io>
      Signed-off-by: default avatarPhil Sutter <phil@nwl.cc>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 08 Aug, 2016 1 commit
  7. 05 Apr, 2016 1 commit
  8. 23 Nov, 2015 4 commits
  9. 17 Aug, 2015 1 commit
    • Phil Sutter's avatar
      rhashtable-test: extend to test concurrency · f4a3e90b
      Phil Sutter authored
      After having tested insertion, lookup, table walk and removal, spawn a
      number of threads running operations on the same rhashtable. Each of
      them will:
      1) insert it's own set of objects,
      2) lookup every successfully inserted object and finally
      3) remove objects in several rounds until all of them have been removed,
         making sure the remaining ones are still found after each round.
      This should put a good amount of load onto the system and due to
      synchronising thread startup via two semaphores also extensive
      concurrent table access.
      The default number of ten threads returned within half a second on my
      local VM with two cores. Running 200 threads took about four seconds. If
      slow systems suffer too much from this though, the default could be
      lowered or even set to zero so this extended test does not run at all by
      Signed-off-by: default avatarPhil Sutter <phil@nwl.cc>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 21 Jul, 2015 1 commit
  11. 05 May, 2015 1 commit
  12. 04 May, 2015 6 commits
  13. 03 Apr, 2015 1 commit
  14. 24 Mar, 2015 1 commit
    • Herbert Xu's avatar
      rhashtable: Add multiple rehash support · b824478b
      Herbert Xu authored
      This patch adds the missing bits to allow multiple rehashes.  The
      read-side as well as remove already handle this correctly.  So it's
      only the rehasher and insertion that need modification to handle
      Note that this patch doesn't actually enable it so for now rehashing
      is still only performed by the worker thread.
      This patch also disables the explicit expand/shrink interface because
      the table is meant to expand and shrink automatically, and continuing
      to export these interfaces unnecessarily complicates the life of the
      rehasher since the rehash process is now composed of two parts.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  15. 20 Mar, 2015 1 commit
  16. 18 Mar, 2015 1 commit
  17. 15 Mar, 2015 1 commit
  18. 27 Feb, 2015 2 commits
    • Daniel Borkmann's avatar
      rhashtable: remove indirection for grow/shrink decision functions · 4c4b52d9
      Daniel Borkmann authored
      Currently, all real users of rhashtable default their grow and shrink
      decision functions to rht_grow_above_75() and rht_shrink_below_30(),
      so that there's currently no need to have this explicitly selectable.
      It can/should be generic and private inside rhashtable until a real
      use case pops up. Since we can make this private, we'll save us this
      additional indirection layer and can improve insertion/deletion time
      as well.
      Reference: http://patchwork.ozlabs.org/patch/443040/Suggested-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Daniel Borkmann's avatar
      rhashtable: unconditionally grow when max_shift is not specified · 8331de75
      Daniel Borkmann authored
      While commit c0c09bfd ("rhashtable: avoid unnecessary wakeup for
      worker queue") rightfully moved part of the decision making of
      whether we should expand or shrink from the expand/shrink functions
      themselves into insert/delete functions in order to avoid unnecessary
      worker wake-ups, it however introduced a regression by doing so.
      Before that change, if no max_shift was specified (= 0) on rhashtable
      initialization, rhashtable_expand() would just grow unconditionally
      and lets the available memory be the limiting factor. After that
      change, if no max_shift was specified, there would be _no_ expansion
      step at all.
      Given that netlink and tipc have a max_shift specified, it was not
      visible there, but Josh Hunt reported that if nft that starts out
      with a default element hint of 3 if not otherwise provided, would
      slow i.e. inserts down trememdously as it cannot grow larger to
      relax table occupancy.
      Given that the test case verifies shrinks/expands manually, we also
      must remove pointer to the helper functions to explicitly avoid
      parallel resizing on insertions/deletions. test_bucket_stats() and
      test_rht_lookup() could also be wrapped around rhashtable mutex to
      explicitly synchronize a walk from resizing, but I think that defeats
      the actual test case which intended to have explicit test steps,
      i.e. 1) inserts, 2) expands, 3) shrinks, 4) deletions, with object
      verification after each stage.
      Reported-by: default avatarJosh Hunt <johunt@akamai.com>
      Fixes: c0c09bfd ("rhashtable: avoid unnecessary wakeup for worker queue")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Ying Xue <ying.xue@windriver.com>
      Cc: Josh Hunt <johunt@akamai.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  19. 20 Feb, 2015 2 commits
  20. 31 Jan, 2015 1 commit