[lttng-dev] Using rculist for dirty tracking

[lttng-dev] Using rculist for dirty tracking

[Lego Lin via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 1043 bytes --]

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

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

[-- Attachment #1.2: Type: text/html, Size: 1394 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

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

Re: [lttng-dev] Using rculist for dirty tracking

[Mathieu Desnoyers via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 1843 bytes --]

----- On Aug 7, 2020, at 3:24 AM, lttng-dev <lttng-dev@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@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 

[-- Attachment #1.2: Type: text/html, Size: 3291 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

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