Re: [patch 1/21] random fixes

Andrew Morton (akpm@zip.com.au)
Mon, 12 Aug 2002 20:03:34 -0700


Adam Kropelin wrote:
>
> On Mon, Aug 12, 2002 at 05:49:40PM -0700, Andrew Morton wrote:
> > Adam Kropelin wrote:
> > >
> > > ...
> > > > You can make 2.5 use the 2.4 settings with
> > > >
> > > > cd /proc/sys/vm
> > > > echo 30 > dirty_background_ratio
> > > > echo 60 > dirty_async_ratio
> > > > echo 70 > dirty_sync_ratio
> > >
> > > These settings bring -akpm in line with stock 2.5.31, but they are both
> > > still slower than 2.4.19 (which itself could do better, I think).
> >
> > In that case I'm confounded. It worked sweetly for me. Just
>
> > Which ftp client are you using? And can you strace it, to see how
> > much data it's writing per system call?
>
> 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:

r b w swpd free buff cache si so bi bo in cs us sy id
0 2 2 5104 4376 0 134016 0 0 0 21620 2888 1966 0 5 95
0 0 2 5104 4448 0 134224 0 0 0 11420 4787 4004 0 8 92
1 0 0 5104 4464 0 134776 0 0 0 100 13133 12564 1 24 75
1 0 0 5104 4440 0 134716 0 0 8 0 13281 12660 1 23 76
0 0 0 5104 4480 0 134448 0 0 56 0 13272 13022 1 22 77
0 1 2 5104 4592 0 133880 0 0 0 27200 2598 1596 0 5 95
0 1 2 5104 4588 0 133880 0 0 0 11544 1127 128 0 2 98
0 0 1 5104 4356 0 134388 0 0 0 692 10383 9839 0 21 79
1 0 0 5104 4368 0 134836 0 0 0 108 13115 12912 1 25 74
0 0 0 5104 4360 0 134556 0 0 36 68 11829 11687 1 20 79

and takes 86 seconds.

When the server is writing to ext2, it is good:

1 0 0 5104 4364 0 135248 0 0 56 12380 13316 16547 1 17 82
0 0 0 5104 4388 0 135296 0 0 0 12324 13310 16488 1 16 83
1 0 0 5104 4056 0 135600 0 0 0 12344 13300 16521 1 15 84
0 0 0 5104 4368 0 135264 0 0 0 12324 13293 16480 0 16 84
1 0 0 5104 4428 0 135184 0 0 0 8216 13306 16514 1 16 83
0 0 0 5104 4396 0 135172 0 0 48 12380 13296 16444 1 16 83
0 0 0 5104 4392 0 135148 0 0 56 12324 13304 16461 1 16 82
1 0 0 5104 4396 0 135196 0 0 0 12324 13297 16468 1 17 82
1 0 0 5104 4444 0 135116 0 0 0 12348 13304 16511 1 18 81

and the transfer takes 54 seconds, which is wirespeed.

The ext3 stall is going to require some thought - it's waiting on a previous
transaction commit so it can get in and modify an inode block again.

Are you _sure_ it was bad with ext2? How long does

dd if=/dev/zero of=foo bs=1M count=600 ; sync

take against that disk?
-
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/