Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757456Ab0DHJIN (ORCPT ); Thu, 8 Apr 2010 05:08:13 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:57603 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751410Ab0DHJIH (ORCPT ); Thu, 8 Apr 2010 05:08:07 -0400 Message-ID: <4BBD9C5A.90307@cn.fujitsu.com> Date: Thu, 08 Apr 2010 17:05:30 +0800 From: Xiao Guangrong User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Michel Lespinasse CC: Hitoshi Mitake , Ingo Molnar , Steven Rostedt , Frederic Weisbecker , Peter Zijlstra , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Ming Lei , LKML Subject: Re: lock's trace events can improve mutex's performance in userspace? References: <4B98BB50.1000002@cn.fujitsu.com> <4B9B1416.5020101@dcl.info.waseda.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1507 Lines: 37 Hi Michel, Michel Lespinasse wrote: > Sorry for the late reply... > > One thing to consider in locking micro-benchmarks is that often, code > changes that slow down parts of the contended code path where the lock > is not held, will result in an increase of the reported > micro-benchmark metric. This effect is particularly marked for > micro-benchmarks that consist of multiple threads doing empty > acquire/release loops. > > As a thought experiment, imagine what would happen if you added a > one-millisecond sleep in the contended code path for mutex > acquisition. Soon all but one of your benchmark threads would be > sleeping, and the only non-sleeping thread would be able to spin on > that lock/unlock loop with no contention, resulting in very nice > results for the micro-benchmark. Remove the sleep and the lock/unlock > threads will have to contend, resulting in lower reported performance > metrics. Great thanks for your valuable reply that makes we see the issue more clearly. I've do the test address your conjecture that add usleep(1) in mutex acquisition path, the test result shows contention is reduced. And i also do the test that does more work in mutex holding path, the result shows optimization ratio is decreased. Thanks, Xiao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/