Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934487AbZAOU66 (ORCPT ); Thu, 15 Jan 2009 15:58:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932889AbZAOUOg (ORCPT ); Thu, 15 Jan 2009 15:14:36 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:56995 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932834AbZAOUOd (ORCPT ); Thu, 15 Jan 2009 15:14:33 -0500 Date: Thu, 15 Jan 2009 12:13:17 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Chris Mason cc: Ingo Molnar , Matthew Wilcox , Peter Zijlstra , "Paul E. McKenney" , Gregory Haskins , Andi Kleen , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , Dmitry Adamushko , Johannes Weiner Subject: Re: [GIT PULL] adaptive spinning mutexes In-Reply-To: <1232047618.8269.93.camel@think.oraclecorp.com> Message-ID: References: <1231863710.7141.3.camel@twins> <1231864854.7141.8.camel@twins> <1231867314.7141.16.camel@twins> <1231952436.14825.28.camel@laptop> <20090114183319.GA18630@elte.hu> <20090114184746.GA21334@elte.hu> <20090114192811.GA19691@elte.hu> <20090115174440.GF29283@parisc-linux.org> <20090115180844.GL22472@elte.hu> <1232047618.8269.93.camel@think.oraclecorp.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1973 Lines: 49 On Thu, 15 Jan 2009, Chris Mason wrote: > On Thu, 2009-01-15 at 10:16 -0800, Linus Torvalds wrote: > > > > Umm. Except if you wrote the code nicely and used spinlocks, you wouldn't > > hold the lock over all those unnecessary and complex operations. > > While this is true, there are examples of places we should expect > speedups for this today. Sure. There are cases where we do have to use sleeping things, because the code is generic and really can't control what lower levels do, and those lower levels have to be able to sleep. So: > Concurrent file creation/deletion in a single dir will often find things > hot in cache and not have to block anywhere (mail spools). The inode->i_mutex thing really does need to use a mutex, and spinning will help. Of course, it should only help when you really have lots of concurrent create/delete/readdir in the same directory, and that hopefully is a very rare load in real life, but hey, it's a valid one. > Concurrent O_DIRECT aio writes to the same file, where i_mutex is > dropped early on. Won't the actual IO costs generally dominate in everything but trivial benchmarks? > pipes should see a huge improvement. Hmm. Pipes may be interesting, but on the other hand, the cases that would see huge improvements would tend to be the cases where the biggest performance gain is from running both sides on the same CPU. The only case where a pipe gets really contended is when both producer and consumer basically do nothing with the data, so the biggest costs is the copy in kernel space (read: pure benchmarking, no real load), and then you often get better performance by scheduling on a single CPU due to cache effects and no lock bouncing. Linus -- 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/