[lttng-dev] A strange problem encountered using urcu-based hash table

[Mathieu Desnoyers]

----- On Dec 18, 2015, at 5:02 AM, 陈志文 <zwchen at 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 at lists.lttng.org
> http://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: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20151218/3d6b98f8/attachment.html>