From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755126AbbFTSCR (ORCPT ); Sat, 20 Jun 2015 14:02:17 -0400 Received: from www.sr71.net ([198.145.64.142]:54228 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754215AbbFTSCK (ORCPT ); Sat, 20 Jun 2015 14:02:10 -0400 Message-ID: <5585AAA0.1030305@sr71.net> Date: Sat, 20 Jun 2015 11:02:08 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: paulmck@linux.vnet.ibm.com CC: Andi Kleen , dave.hansen@linux.intel.com, akpm@linux-foundation.org, jack@suse.cz, viro@zeniv.linux.org.uk, eparis@redhat.com, john@johnmccutchan.com, rlove@rlove.org, tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] fs: optimize inotify/fsnotify code for unwatched files References: <20150619215025.4F689817@viggo.jf.intel.com> <20150619233306.GT25760@tassilo.jf.intel.com> <5584B62F.5080506@sr71.net> <20150620022135.GF3913@linux.vnet.ibm.com> In-Reply-To: <20150620022135.GF3913@linux.vnet.ibm.com> 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 On 06/19/2015 07:21 PM, Paul E. McKenney wrote: >>> > > What is so expensive in it? Just the memory barrier in it? >> > >> > The profiling doesn't hit on the mfence directly, but I assume that the >> > overhead is coming from there. The "mov 0x8(%rdi),%rcx" is identical >> > before and after the barrier, but it appears much more expensive >> > _after_. That makes no sense unless the barrier is the thing causing it. > OK, one thing to try is to simply delete the memory barrier. The > resulting code will be unsafe, but will probably run well enough to > get benchmark results. If it is the memory barrier, you should of > course get increased throughput. So I took the smp_mb() out of __srcu_read_lock(). The benchmark didn't improve at all. Looking at the profile, all of the overhead had just shifted to __srcu_read_unlock() and its memory barrier! Removing the barrier in __srcu_read_unlock() got essentially the same gains out of the benchmark as the original patch in this thread that just avoids RCU. I think that's fairly conclusive that the source of the overhead is, indeed, the memory barriers. Although I said this test was single threaded, I also had another thought. The benchmark is single-threaded, but 'perf' is sitting doing profiling and who knows what else on the other core, and the profiling NMIs are certainly writing plenty of data to memory. So, there might be plenty of work for that smp_mb()/mfence to do _despite_ the benchmark itself being single threaded. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/