From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mathieu Desnoyers Subject: Re: A strange problem encountered using urcu-based hash table Date: Fri, 18 Dec 2015 20:26:30 +0000 (UTC) Message-ID: <2117619532.264122.1450470390420.JavaMail.zimbra__39465.4960641221$1450470463$gmane$org@efficios.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1212705054==" Return-path: Received: from mail.efficios.com ([78.47.125.74]) by ltt.polymtl.ca with esmtp (Exim 4.80) (envelope-from ) id 1aA1br-0006Fi-Mj for lttng-dev@lists.lttng.org; Fri, 18 Dec 2015 15:26:45 -0500 In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lttng-dev-bounces@lists.lttng.org To: =?utf-8?B?6ZmI5b+X5paH?= Cc: lttng-dev List-Id: lttng-dev@lists.lttng.org --===============1212705054== Content-Type: multipart/alternative; boundary="----=_Part_264121_1561099078.1450470390419" ------=_Part_264121_1561099078.1450470390419 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- On Dec 18, 2015, at 5:02 AM, =E9=99=88=E5=BF=97=E6=96=87 wrote:=20 > Hi, I'm a Ph.D from Hunan University of China. Recently, our group are te= nding > to analysis concurrent hash tables using different synchronization mechan= isms, > 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 utilizati= on is > only 3% (while in a read-only workload, the CPU utilization is 50%). Is t= here > any writer performance limits for urcu? Or why this happened in your eye? > There is our platform information: Intel SandyBridge EP with 2 sockets, e= ach > 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=20 from your updater thread ? This would very likely explain a low CPU utiliza= tion.=20 I would recommend using the call_rcu() mechanism to batch those synchronize= _rcu()=20 calls if you don't use it already.=20 If it's not your situation, then emailing us a copy of your test code would= likely help us=20 pinpoint the slowdown cause.=20 Thanks,=20 Mathieu=20 > 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 --=20 Mathieu Desnoyers=20 EfficiOS Inc.=20 http://www.efficios.com=20 ------=_Part_264121_1561099078.1450470390419 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

----- On Dec 18, 2015, at 5:02 AM, =E9=99=88=E5=BF=97=E6=96= =87 <zwchen@aimlab.org> wrote:
Hi, I'm a Ph.D from Hunan University of China. Recently, our grou= p are tending to analysis concurrent hash tables using different synchroniz= ation mechanisms, urcu-based hashing is one of our targets. Today, we runni= ng an urcu-based hash table with only ten percent update operations. We fou= nd its CPU utilization is only 3% (while in a read-only workload, the CPU u= tilization is 50%). Is there any writer performance limits for urcu? Or why= this happened in your eye?
There is our platform information: Inte= l SandyBridge EP with 2 sockets, each sockets with 8 cores and 2 physical t= hreads for each core. OS: Ubuntu 14.04 LTS.
Experimental configur= ation: 16 threads, ten percent of update operations and 1 million initial e= lements in hash table.

Are you = invoking "synchronize_rcu()" after each removal from the hash table directl= y
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 email= ing 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@li= sts.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev<= br>

--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com ------=_Part_264121_1561099078.1450470390419-- --===============1212705054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev --===============1212705054==--