Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161299AbXAHNnQ (ORCPT ); Mon, 8 Jan 2007 08:43:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161298AbXAHNnQ (ORCPT ); Mon, 8 Jan 2007 08:43:16 -0500 Received: from srv5.dvmed.net ([207.36.208.214]:54682 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161291AbXAHNnP (ORCPT ); Mon, 8 Jan 2007 08:43:15 -0500 Message-ID: <45A24A65.1070706@garzik.org> Date: Mon, 08 Jan 2007 08:43:01 -0500 From: Jeff Garzik User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: Theodore Tso , Suparna Bhattacharya , Andrew Morton , Willy Tarreau , Linus Torvalds , "H. Peter Anvin" , git@vger.kernel.org, nigel@nigel.suspend2.net, "J.H." , Randy Dunlap , Pavel Machek , kernel list , webmaster@kernel.org, "linux-ext4@vger.kernel.org" Subject: Re: How git affects kernel.org performance References: <1166297434.26330.34.camel@localhost.localdomain> <1166304080.13548.8.camel@nigel.suspend2.net> <459152B1.9040106@zytor.com> <1168140954.2153.1.camel@nigel.suspend2.net> <45A08269.4050504@zytor.com> <45A083F2.5000000@zytor.com> <20070107085526.GR24090@1wt.eu> <20070107011542.3496bc76.akpm@osdl.org> <20070108030555.GA7289@in.ibm.com> <20070108125819.GA32756@thunk.org> In-Reply-To: <20070108125819.GA32756@thunk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.3 (----) X-Spam-Report: SpamAssassin version 3.1.7 on srv5.dvmed.net summary: Content analysis details: (-4.3 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1140 Lines: 25 Theodore Tso wrote: > The fastest and probably most important thing to add is some readahead > smarts to directories --- both to the htree and non-htree cases. If > you're using some kind of b-tree structure, such as XFS does for > directories, preallocation doesn't help you much. Delayed allocation > can save you if your delayed allocator knows how to structure disk > blocks so that a btree-traversal is efficient, but I'm guessing the > biggest reason why we are losing is because we don't have sufficient > readahead. This also has the advantage that it will help without > needing to doing a backup/restore to improve layout. Something I just thought of: ATA and SCSI hard disks do their own read-ahead. Seeking all over the place to pick up bits of directory will hurt even more with the disk reading and throwing away data (albeit in its internal elevator and cache). Jeff - 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/