Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 13 Aug 2002 01:18:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 13 Aug 2002 01:18:18 -0400 Received: from parcelfarce.linux.theplanet.co.uk ([195.92.249.252]:19470 "EHLO www.linux.org.uk") by vger.kernel.org with ESMTP id ; Tue, 13 Aug 2002 01:18:16 -0400 Message-ID: <3D5899DB.B087E40D@zip.com.au> Date: Mon, 12 Aug 2002 22:32:11 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Adam Kropelin CC: lkml , riel@conectiva.com.br Subject: Re: [patch 1/21] random fixes References: <3D56146B.C3CAB5E1@zip.com.au> <20020811142938.GA681@www.kroptech.com> <3D56A83E.ECF747C6@zip.com.au> <20020812002739.GA778@www.kroptech.com> <3D57406E.D39E9B89@zip.com.au> <20020813002603.GA20817@www.kroptech.com> <3D5857A4.FE358FA2@zip.com.au> <20020813022550.GA6810@www.kroptech.com> <3D587706.A0F2DC21@zip.com.au> <20020813041011.GA12227@www.kroptech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4110 Lines: 99 Adam Kropelin wrote: > > On Mon, Aug 12, 2002 at 08:03:34PM -0700, Andrew Morton wrote: > > Adam Kropelin wrote: > > > Actually, I'm running an FTP server on the testbed machine and pushing the > > > data from a client on another (much faster) machine. I straced the server > > > (redhat wu-ftpd2.6.1-20) and it looks like 8 KB reads/writes. > > > > > > > OK, tried that against a slow disk (13 megs/sec write bandwidth). 2.5.31, > > defalt writeback settings. > > > > ext3 is misbehaving: > > and takes 86 seconds. > > > > When the server is writing to ext2, it is good: > > and the transfer takes 54 seconds, which is wirespeed. > > > > Are you _sure_ it was bad with ext2? > > Yes. > > [root@devbox adk0212] mount > /dev/hda3 on / type ext2 (rw) > none on /proc type proc (rw) > /dev/hda1 on /boot type ext2 (rw) > none on /dev/pts type devpts (rw,gid=5,mode=620) > none on /dev/shm type tmpfs (rw) > > procs memory swap io system cpu > r b w swpd free buff cache si so bi bo in cs us sy id > 0 1 1 120 4360 0 141132 0 0 0 9804 6775 564 0 45 55 > 0 1 1 120 4344 0 141132 0 0 0 0 1083 20 0 0 99 > 0 0 0 120 4364 0 141116 0 0 0 40 2098 156 0 11 89 > 0 0 0 120 4384 0 141368 0 0 0 4 7013 594 0 52 47 > 0 0 0 120 4360 0 141416 0 0 0 0 6914 589 1 56 43 > 0 1 1 120 4464 0 140856 0 0 0 15420 6235 520 0 42 58 > 0 1 1 120 4456 0 140856 0 0 0 3240 1094 36 0 2 98 > 1 0 0 120 4428 0 140844 0 0 0 52 1151 70 0 4 96 > 1 0 0 120 4440 0 141356 0 0 0 4 6810 541 1 42 57 > 0 0 0 120 4464 0 141320 0 0 0 0 6894 553 1 40 58 > 0 1 1 120 4396 0 140840 0 0 0 15508 6018 466 0 40 59 > 0 1 1 120 4388 0 140840 0 0 0 1608 1093 57 0 2 98 > 0 0 0 120 4404 0 140832 0 0 0 52 2350 165 0 12 87 > 0 0 0 120 4460 0 141380 0 0 0 4 7040 564 1 42 57 > 1 0 0 120 4356 0 141372 0 0 0 4 7073 570 1 45 54 > ... Sure looks like ext3. > > Is it possible that the darn thing is mounted ext3 even though fstab and mount > agree that it's ext2? Yes. Although it's usually the other way round. "How come it keeps running fsck even though mount says ext3?". Take a look in /proc/mounts. > > How long does > > > > dd if=/dev/zero of=foo bs=1M count=600 ; sync > > > > take against that disk? > > 1m 23s (I said it was a slow disk ;) gack. I've seen pencils which can write faster than that. So your wirespeed actually exceeds the disk speed. That changes things. The kernel *has* to stall the generator of dirty data. We can make the stalls shorter, and more frequent. Go into drivers/block/ll_rw_blk.c and see where it's initialising batch_requests. Just change it to batch_requests = 1; batch_requests needs to die anyhow... And in fs/mpage.c, set RATELIMIT_PAGES to 16. The application has to block, but the disk should certainly never fall idle. I'll play with this a bit. IDE ceased to be an option in 2.5.30, which does not aid this effort. > I've been trying these sorts of tests on this machine for over a year now, > with various disk subsystems, and I have *never* seen anything as nice and > consistent as the ext2 writeout you quoted. Maybe this machine is cursed. > Lumpy writeback is pretty common. As is bad latency during writeout. It's quite tricky to get these things balanced out, and it's easy to fix one thing and break another. Not a lot of effort has been put into fine tuning 2.5 for smoothness and latency thus far. - 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/