A strange problem encountered using urcu-based hash table

A strange problem encountered using urcu-based hash table

[陈志文]

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

Hi, I'm a Ph.D from Hunan University of China. Recently, our group are
tending to analysis concurrent hash tables using different synchronization
mechanisms, urcu-based hashing is one of our targets. Today, we running an
urcu-based hash table with only ten percent update operations. We found its
CPU utilization is only 3% (while in a read-only workload, the CPU
utilization is 50%). Is there any writer performance limits for urcu? Or
why this happened in your eye?

There is our platform information: Intel SandyBridge EP with 2 sockets,
each sockets with 8 cores and 2 physical threads for each core. OS: Ubuntu
14.04 LTS.
Experimental configuration: 16 threads, ten percent of update operations
and 1 million initial elements in hash table.

We are looking forward for your reply.

Thanks!

-- 
aimlab zwchen

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

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

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

Re: A strange problem encountered using urcu-based hash table

[Mathieu Desnoyers]

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

----- On Dec 18, 2015, at 5:02 AM, 陈志文 <zwchen@aimlab.org> wrote: 

> Hi, I'm a Ph.D from Hunan University of China. Recently, our group are tending
> to analysis concurrent hash tables using different synchronization mechanisms,
> urcu-based hashing is one of our targets. Today, we running an urcu-based hash
> table with only ten percent update operations. We found its CPU utilization is
> only 3% (while in a read-only workload, the CPU utilization is 50%). Is there
> any writer performance limits for urcu? Or why this happened in your eye?
> There is our platform information: Intel SandyBridge EP with 2 sockets, each
> sockets with 8 cores and 2 physical threads for each core. OS: Ubuntu 14.04
> LTS.
> Experimental configuration: 16 threads, ten percent of update operations and 1
> million initial elements in hash table.

Are you invoking "synchronize_rcu()" after each removal from the hash table directly 
from your updater thread ? This would very likely explain a low CPU utilization. 

I would recommend using the call_rcu() mechanism to batch those synchronize_rcu() 
calls if you don't use it already. 

If it's not your situation, then emailing us a copy of your test code would likely help us 
pinpoint the slowdown cause. 

Thanks, 

Mathieu 

> We are looking forward for your reply.

> Thanks!

> --
> aimlab zwchen

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

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

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

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

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