Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 9 Nov 2001 03:49:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 9 Nov 2001 03:49:29 -0500 Received: from adsl-206-170-148-147.dsl.snfc21.pacbell.net ([206.170.148.147]:5125 "HELO gw.goop.org") by vger.kernel.org with SMTP id ; Fri, 9 Nov 2001 03:49:19 -0500 Subject: Re: [Ext2-devel] disk throughput From: Jeremy Fitzhardinge To: Andrew Morton Cc: Constantin Loizides , Linux Kernel List In-Reply-To: <3BEB72DA.7ADA8332@zip.com.au> In-Reply-To: <3BEAA3B7.A7F9328E@isg.de>, <3BE647F4.AD576FF2@zip.com.au> <3BE71131.59BA0CFC@zip.com.au> <20011106105138Z16653-12382+40@humbolt.nl.linux.org> <1005063444.25686.18.camel@ixodes.goop.org> <3BEAA3B7.A7F9328E@isg.de> <1005237961.4537.0.camel@ixodes.goop.org> <3BEB72DA.7ADA8332@zip.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 09 Nov 2001 00:49:17 -0800 Message-Id: <1005295757.5672.4.camel@ixodes.goop.org> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2001-11-08 at 22:08, Andrew Morton wrote: > How do you avoid aftifacts from Linux caching with this test? Randomly seeking around a 40G disk isn't going to give the caching much to work with (that was on a 256Mbyte machine). Also, I tried it with raw devices, but it made no difference to the measurements. > > I found the random seeking was the only way I could get reasonable > > numbers out of the drive; any of the ordered patterns of the form "OK, > > lets measure N block seeks" seemed to be predicted by the drive and gave > > unreasonably fast results. > > > > But we *want* unreasonably fast results! We need to understand > this device-level prediction, then decide if it's sufficiently > widespread for us to go and exploit the hell out of it. > > Have you any ideas as to what's happening? Not really. I wanted results which at least confirm the simple model of how the disk works. When I did deterministic seeks, it was something like: for(n = 0; n < disksize/2; n += about_a_cylinder) { seek(n); read(); seek(disksize-n); read(); } I suspect that the drive was partitioning its cache and using lots of readahead to satisfy the reads at either end of the seek. I was trying to work around that by making the n increment large enough, but it didn't seem to work. Maybe the drive was being extra special clever, or maybe I miscalculated the cylinder size. Or maybe I just happened to be hitting a rotational sweet-spot. For this kind of test, it would be interesting to know what differences there are between read and write. In principle the drive could start writing a track anywhere it wants so long as it has enough to write the whole thing. That would automatically make it get the track-track skew right... J - 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/