• Michel Lespinasse's avatar
    rbtree: add prio tree and interval tree tests · fff3fd8a
    Michel Lespinasse authored
    Patch 1 implements support for interval trees, on top of the augmented
    rbtree API. It also adds synthetic tests to compare the performance of
    interval trees vs prio trees. Short answers is that interval trees are
    slightly faster (~25%) on insert/erase, and much faster (~2.4 - 3x)
    on search. It is debatable how realistic the synthetic test is, and I have
    not made such measurements yet, but my impression is that interval trees
    would still come out faster.
    Patch 2 uses a preprocessor template to make the interval tree generic,
    and uses it as a replacement for the vma prio_tree.
    Patch 3 takes the other prio_tree user, kmemleak, and converts it to use
    a basic rbtree. We don't actually need the augmented rbtree support here
    because the intervals are always non-overlapping.
    Patch 4 removes the now-unused prio tree library.
    Patch 5 proposes an additional optimization to rb_erase_augmented, now
    providing it as an inline function so that the augmented callbacks can be
    inlined in. This provides an additional 5-10% performance improvement
    for the interval tree insert/erase benchmark. There is a maintainance cost
    as it exposes augmented rbtree users to some of the rbtree library internals;
    however I think this cost shouldn't be too high as I expect the augmented
    rbtree will always have much less users than the base rbtree.
    I should probably add a quick summary of why I think it makes sense to
    replace prio trees with augmented rbtree based interval trees now.  One of
    the drivers is that we need augmented rbtrees for Rik's vma gap finding
    code, and once you have them, it just makes sense to use them for interval
    trees as well, as this is the simpler and more well known algorithm.  prio
    trees, in comparison, seem *too* clever: they impose an additional 'heap'
    constraint on the tree, which they use to guarantee a faster worst-case
    complexity of O(k+log N) for stabbing queries in a well-balanced prio
    tree, vs O(k*log N) for interval trees (where k=number of matches,
    N=number of intervals).  Now this sounds great, but in practice prio trees
    don't realize this theorical benefit.  First, the additional constraint
    makes them harder to update, so that the kernel implementation has to
    simplify things by balancing them like a radix tree, which is not always
    ideal.  Second, the fact that there are both index and heap properties
    makes both tree manipulation and search more complex, which results in a
    higher multiplicative time constant.  As it turns out, the simple interval
    tree algorithm ends up running faster than the more clever prio tree.
    This patch:
    Add two test modules:
    - prio_tree_test measures the performance of lib/prio_tree.c, both for
      insertion/removal and for stabbing searches
    - interval_tree_test measures the performance of a library of equivalent
      functionality, built using the augmented rbtree support.
    In order to support the second test module, lib/interval_tree.c is
    introduced. It is kept separate from the interval_tree_test main file
    for two reasons: first we don't want to provide an unfair advantage
    over prio_tree_test by having everything in a single compilation unit,
    and second there is the possibility that the interval tree functionality
    could get some non-test users in kernel over time.
    Signed-off-by: 's avatarMichel Lespinasse <walken@google.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Hillf Danton <dhillf@gmail.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
interval_tree.h 757 Bytes