1. 24 3月, 2015 1 次提交
    • H
      rhashtable: Add multiple rehash support · b824478b
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b824478b
  2. 21 3月, 2015 1 次提交
  3. 19 3月, 2015 1 次提交
  4. 15 3月, 2015 1 次提交
  5. 28 2月, 2015 2 次提交
    • D
      rhashtable: remove indirection for grow/shrink decision functions · 4c4b52d9
      Daniel Borkmann 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c4b52d9
    • D
      rhashtable: unconditionally grow when max_shift is not specified · 8331de75
      Daniel Borkmann 提交于
      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: NJosh Hunt <johunt@akamai.com>
      Fixes: c0c09bfd ("rhashtable: avoid unnecessary wakeup for worker queue")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Ying Xue <ying.xue@windriver.com>
      Cc: Josh Hunt <johunt@akamai.com>
      Acked-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8331de75
  6. 21 2月, 2015 2 次提交
  7. 31 1月, 2015 1 次提交