1. 05 Apr, 2016 1 commit
  2. 23 Nov, 2015 4 commits
  3. 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
      default.
      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>
      f4a3e90b
  4. 21 Jul, 2015 1 commit
  5. 05 May, 2015 1 commit
  6. 03 May, 2015 6 commits
  7. 03 Apr, 2015 1 commit
  8. 23 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
      this.
      
      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>
      b824478b
  9. 20 Mar, 2015 1 commit
  10. 18 Mar, 2015 1 commit
  11. 14 Mar, 2015 1 commit
  12. 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>
      4c4b52d9
    • 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>
      8331de75
  13. 20 Feb, 2015 2 commits
  14. 30 Jan, 2015 1 commit