Messages in this thread | | | Date | Mon, 04 May 2020 16:15:55 -0400 | Subject | Re: [PATCH 09/24] rcu/tree: cache specified number of objects | From | joel@joelfern ... |
| |
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.
| |