lkml.org 
[lkml]   [2020]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 09/24] rcu/tree: cache specified number of objects
    From


    On May 4, 2020 3:51:28 PM EDT, Uladzislau Rezki <urezki@gmail.com> wrote:
    >> > > Since we don't care about traversing backwards, isn't it better
    >to use llist
    >> > > for this usecase?
    >> > >
    >> > > I think Vlad is using locking as we're also tracking the size of
    >the llist to
    >> > > know when to free pages. This tracking could suffer from the
    >lost-update
    >> > > problem without any locking, 2 lockless llist_add happened
    >simulatenously.
    >> > >
    >> > > Also if list_head is used, it will take more space and still use
    >locking.
    >> >
    >> > Indeed, it would be best to use a non-concurrent singly linked
    >list.
    >>
    >> Ok cool :-)
    >>
    >> Is it safe to say something like the following is ruled out? ;-) :-D
    >> #define kfree_rcu_list_add llist_add
    >>
    >In that case i think it is better just to add a comment about using
    >llist_head. To state that it used as a singular list to save space
    >and the access is synchronized by the lock :)
    >
    >IMHO.

    Sounds good to me. thanks,

    - Joel

    >
    >--
    >Vlad Rezki

    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.

    \
     
     \ /
      Last update: 2020-05-04 22:16    [W:4.208 / U:0.528 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site