[lttng-dev] Using rculist for dirty tracking

[Mathieu Desnoyers]

----- On Aug 7, 2020, at 3:24 AM, lttng-dev <lttng-dev at lists.lttng.org> wrote: 

> Hi,
> I am new for using rcu and I need some helps for integrating user space rcu into
> my project for solving performance issue.
> In my project, I create 2 link list - one for free pool, one for using pool.
> Free pool used to hold a segment of memory that no-one use.
> Using pool used to hold a segment of memory that someone use.
> Originally, I use a pthread_spin_lock to protect
> 1. alloc memory segment from free pool, and move memory segment from free pool
> to using pool
> 2. free memory segment from using pool, and move memory segment from free pool
> to using pool

I suspect we would need to know the entire intended design here in order to start 
a discussion. What operations are doing list traversals ? What operations are doing 
updates ? How frequently are each respective operation done ? Do you intend to 
keep your spin lock to protect concurrent list updates, and if not how do you plan on 
protecting concurrent updates ? 

What are the performance issues you are experiencing exactly ? 

Thanks, 

Mathieu 

> For RCU, I change the list_move_tail as following
> cds_list_for_each_entry_safe(cur, next, &(membk_pool->bk_free_pool), entry_pool)
> {
> cds_list_del_rcu(&cur->entry_pool);
> urcu_bp_synchronize_rcu();
> cds_list_add_tail_rcu(&ret->entry_pool, &(membk_pool->bk_using_pool));
> }

> Is it ok to use scenario like this?

> Meanwhile, that are some advance list operation API:
> 1. list_first_entry
> 2. list_first_entry_or_null
> Is it possible to integrate these into current urcu?

> Thanks

> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20200807/96268ff8/attachment.htm>