• H
    tmpfs radix_tree: locate_item to speed up swapoff · e504f3fd
    Hugh Dickins 提交于
    We have already acknowledged that swapoff of a tmpfs file is slower than
    it was before conversion to the generic radix_tree: a little slower
    there will be acceptable, if the hotter paths are faster.
    
    But it was a shock to find swapoff of a 500MB file 20 times slower on my
    laptop, taking 10 minutes; and at that rate it significantly slows down
    my testing.
    
    Now, most of that turned out to be overhead from PROVE_LOCKING and
    PROVE_RCU: without those it was only 4 times slower than before; and
    more realistic tests on other machines don't fare as badly.
    
    I've tried a number of things to improve it, including tagging the swap
    entries, then doing lookup by tag: I'd expected that to halve the time,
    but in practice it's erratic, and often counter-productive.
    
    The only change I've so far found to make a consistent improvement, is
    to short-circuit the way we go back and forth, gang lookup packing
    entries into the array supplied, then shmem scanning that array for the
    target entry.  Scanning in place doubles the speed, so it's now only
    twice as slow as before (or three times slower when the PROVEs are on).
    
    So, add radix_tree_locate_item() as an expedient, once-off,
    single-caller hack to do the lookup directly in place.  #ifdef it on
    CONFIG_SHMEM and CONFIG_SWAP, as much to document its limited
    applicability as save space in other configurations.  And, sadly,
    #include sched.h for cond_resched().
    Signed-off-by: NHugh Dickins <hughd@google.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    e504f3fd
radix-tree.c 39.5 KB