26 Jul, 2017

1 commit


25 Jul, 2017

1 commit

  • 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: f4a3e90ba5739 ("rhashtable-test: extend to test concurrency")
    Reported by: Manuel Messner
    Signed-off-by: Phil Sutter
    Acked-by: Herbert Xu
    Signed-off-by: David S. Miller

    Phil Sutter
     

09 Aug, 2016

1 commit


05 Apr, 2016

1 commit

  • In certain cases, the 802.11 mesh pathtable code wants to
    iterate over all of the entries in the forwarding table from
    the receive path, which is inside an RCU read-side critical
    section. Enable walks inside atomic sections by allowing
    GFP_ATOMIC allocations for the walker state.

    Change all existing callsites to pass in GFP_KERNEL.

    Acked-by: Thomas Graf
    Signed-off-by: Bob Copeland
    [also adjust gfs2/glock.c and rhashtable tests]
    Signed-off-by: Johannes Berg

    Bob Copeland
     

24 Nov, 2015

4 commits

  • This is rather a hack to expose the current issue with rhashtable to
    under high pressure sometimes return -ENOMEM even though system memory
    is not exhausted and a consecutive insert may succeed.

    Signed-off-by: Phil Sutter
    Signed-off-by: David S. Miller

    Phil Sutter
     
  • A maximum table size of 64k entries is insufficient for the multiple
    threads test even in default configuration (10 threads * 50000 objects =
    500000 objects in total). Since we know how many objects will be
    inserted, calculate the max size unless overridden by parameter.

    Note that specifying the exact number of objects upon table init won't
    suffice as that value is being rounded down to the next power of two -
    anticipate this by rounding up to the next power of two in beforehand.

    Signed-off-by: Phil Sutter
    Signed-off-by: David S. Miller

    Phil Sutter
     
  • After adding cond_resched() calls to threadfunc(), a surprisingly high
    rate of insert failures occurred probably due to table resizes getting a
    better chance to run in background. To not soften up the remaining
    tests, retry inserts until they either succeed or fail permanently.

    Also change the non-threaded test to retry insert operations, too.

    Suggested-by: Thomas Graf
    Signed-off-by: Phil Sutter
    Signed-off-by: David S. Miller

    Phil Sutter
     
  • This should fix for soft lockup bugs triggered on slow systems.

    Signed-off-by: Phil Sutter
    Signed-off-by: David S. Miller

    Phil Sutter
     

18 Aug, 2015

1 commit

  • 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: Phil Sutter
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Phil Sutter
     

21 Jul, 2015

1 commit


06 May, 2015

1 commit

  • A 64bit division went in unnoticed. Use do_div() to accomodate
    non 64bit architectures.

    Reported-by: kbuild test robot
    Fixes: 1aa661f5c3df ("rhashtable-test: Measure time to insert, remove & traverse entries")
    Signed-off-by: Thomas Graf
    Signed-off-by: David S. Miller

    Thomas Graf
     

04 May, 2015

6 commits


04 Apr, 2015

1 commit


24 Mar, 2015

1 commit

  • 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: Herbert Xu
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Herbert Xu
     

21 Mar, 2015

1 commit


19 Mar, 2015

1 commit


15 Mar, 2015

1 commit

  • This patch adds a rehash counter to bucket_table to indicate
    the last bucket that has been rehashed. This serves two purposes:

    1. Any bucket that has been rehashed can never gain a new object.
    2. If the rehash counter reaches the size of the table, the table
    will forever remain empty.

    This patch also downsizes bucket_table->size to an unsigned int
    since we do not support sizes greater than 32 bits yet.

    Signed-off-by: Herbert Xu
    Signed-off-by: David S. Miller

    Herbert Xu
     

28 Feb, 2015

2 commits

  • 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: David S. Miller
    Signed-off-by: Daniel Borkmann
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Daniel Borkmann
     
  • While commit c0c09bfdc415 ("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: Josh Hunt
    Fixes: c0c09bfdc415 ("rhashtable: avoid unnecessary wakeup for worker queue")
    Signed-off-by: Daniel Borkmann
    Cc: Ying Xue
    Cc: Josh Hunt
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Daniel Borkmann
     

21 Feb, 2015

2 commits

  • There's no good reason why to disallow unloading of the rhashtable
    test case module.

    Commit 9d6dbe1bbaf8 moved the code from a boot test into a stand-alone
    module, but only converted the subsys_initcall() handler into a
    module_init() function without a related exit handler, and thus
    preventing the test module from unloading.

    Fixes: 9d6dbe1bbaf8 ("rhashtable: Make selftest modular")
    Signed-off-by: Daniel Borkmann
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Daniel Borkmann
     
  • With object runtime debugging enabled, the rhashtable test suite
    will rightfully throw a warning "ODEBUG: object is on stack, but
    not annotated" from rhashtable_init().

    This is because run_work is (correctly) being initialized via
    INIT_WORK(), and not annotated by INIT_WORK_ONSTACK(). Meaning,
    rhashtable_init() is okay as is, we just need to move ht e.g.,
    into global scope.

    It never triggered anything, since test_rhashtable is rather a
    controlled environment and effectively runs to completion, so
    that stack memory is not vanishing underneath us, we shouldn't
    confuse any testers with it though.

    Fixes: 7e1e77636e36 ("lib: Resizable, Scalable, Concurrent Hash Table")
    Signed-off-by: Daniel Borkmann
    Acked-by: Thomas Graf
    Signed-off-by: David S. Miller

    Daniel Borkmann
     

31 Jan, 2015

1 commit