lkml.org 
[lkml]   [2023]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 2/4] mm: vmalloc: use rwsem, mutex for vmap_area_lock and vmap_block->lock
    On Mon, Mar 20, 2023 at 08:54:33AM +0100, Uladzislau Rezki wrote:
    > > vmalloc() is, by design, not permitted to be used in atomic context and
    > > already contains components which may sleep, so avoiding spin locks is not
    > > a problem from the perspective of atomic context.
    > >
    > > The global vmap_area_lock is held when the red/black tree rooted in
    > > vmap_are_root is accessed and thus is rather long-held and under
    > > potentially high contention. It is likely to be under contention for reads
    > > rather than write, so replace it with a rwsem.
    > >
    > > Each individual vmap_block->lock is likely to be held for less time but
    > > under low contention, so a mutex is not an outrageous choice here.
    > >
    > > A subset of test_vmalloc.sh performance results:-
    > >
    > > fix_size_alloc_test 0.40%
    > > full_fit_alloc_test 2.08%
    > > long_busy_list_alloc_test 0.34%
    > > random_size_alloc_test -0.25%
    > > random_size_align_alloc_test 0.06%
    > > ...
    > > all tests cycles 0.2%
    > >
    > > This represents a tiny reduction in performance that sits barely above
    > > noise.
    > >
    > How important to have many simultaneous users of vread()? I do not see a
    > big reason to switch into mutexes due to performance impact and making it
    > less atomic.

    It's less about simultaneous users of vread() and more about being able to write
    direct to user memory rather than via a bounce buffer and not hold a spinlock
    over possible page faults.

    The performance impact is barely above noise (I got fairly widely varying
    results), so I don't think it's really much of a cost at all. I can't imagine
    there are many users critically dependent on a sub-single digit % reduction in
    speed in vmalloc() allocation.

    As I was saying to Willy, the code is already not atomic, or rather needs rework
    to become atomic-safe (there are a smattering of might_sleep()'s throughout)

    However, given your objection alongside Willy's, let me examine Willy's
    suggestion that we instead of doing this, prefault the user memory in advance of
    the vread call.

    >
    > So, how important for you to have this change?
    >

    Personally, always very important :)

    > --
    > Uladzislau Rezki

    \
     
     \ /
      Last update: 2023-03-27 01:07    [W:4.014 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site