[lttng-dev] A strange problem encountered using urcu-based hash table
mathieu.desnoyers at efficios.com
Fri Dec 18 15:26:30 EST 2015
----- 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
> 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.
> We are looking forward for your reply.
> aimlab zwchen
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lttng-dev