Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757453AbYHGMwe (ORCPT ); Thu, 7 Aug 2008 08:52:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756604AbYHGMvs (ORCPT ); Thu, 7 Aug 2008 08:51:48 -0400 Received: from agminet02.oracle.com ([141.146.126.229]:61976 "EHLO agminet02.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756524AbYHGMvq (ORCPT ); Thu, 7 Aug 2008 08:51:46 -0400 Subject: Re: Btrfs v0.16 released From: Chris Mason To: Peter Zijlstra Cc: linux-btrfs , linux-kernel , linux-fsdevel In-Reply-To: <1218100139.8625.7.camel@twins> References: <1217962876.15342.33.camel@think.oraclecorp.com> <1218100139.8625.7.camel@twins> Content-Type: text/plain Date: Thu, 07 Aug 2008 06:34:02 -0400 Message-Id: <1218105242.15342.184.camel@think.oraclecorp.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1667 Lines: 41 On Thu, 2008-08-07 at 11:08 +0200, Peter Zijlstra wrote: > On Tue, 2008-08-05 at 15:01 -0400, Chris Mason wrote: > > > * Fine grained btree locking. The large fs_mutex is finally gone. > > There is still some work to do on the locking during extent allocation, > > but the code is much more scalable than it was. > > Cool - will try to find a cycle to stare at the code ;-) > I was able to get it mostly lockdep complaint by using mutex_lock_nested based on the level of the btree I was locking. My allocation mutex is a little of a problem for lockdep though. > > * Helper threads for checksumming and other background tasks. Most CPU > > intensive operations have been pushed off to helper threads to take > > advantage of SMP machines. Streaming read and write throughput now > > scale to disk speed even with checksumming on. > > Can this lead to the same Priority Inversion issues as seen with > kjournald? > Yes, although in general only the helper threads end up actually doing the IO for writes. Unfortunately, they are almost but not quite an elevator. It is tempting to try sorting the bios on the helper queues etc. But I haven't done that because it gets into starvation and other fun. I haven't done any real single cpu testing, it may make sense in those workloads to checksum and submit directly in the calling context. But real single cpu boxes are harder to come by these days. -chris -- 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/