public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Adam Kropelin <akropel1@rochester.rr.com>
Cc: lkml <linux-kernel@vger.kernel.org>, riel@conectiva.com.br
Subject: Re: [patch 1/21] random fixes
Date: Mon, 12 Aug 2002 22:32:11 -0700	[thread overview]
Message-ID: <3D5899DB.B087E40D@zip.com.au> (raw)
In-Reply-To: 20020813041011.GA12227@www.kroptech.com

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.

  parent reply	other threads:[~2002-08-13  5:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-11  7:38 [patch 1/21] random fixes Andrew Morton
2002-08-11  7:56 ` Alexander Viro
2002-08-11 14:29 ` Adam Kropelin
2002-08-11 18:09   ` Andrew Morton
2002-08-12  0:27     ` Adam Kropelin
2002-08-12  0:41       ` Rik van Riel
2002-08-12  4:58       ` Andrew Morton
2002-08-13  0:26         ` Adam Kropelin
2002-08-13  0:49           ` Andrew Morton
2002-08-13  2:25             ` Adam Kropelin
2002-08-13  3:03               ` Andrew Morton
2002-08-13  4:10                 ` Adam Kropelin
2002-08-13  5:25                   ` Andreas Dilger
2002-08-13 12:37                     ` Adam Kropelin
2002-08-13 17:21                       ` Andreas Dilger
2002-08-13  5:32                   ` Andrew Morton [this message]
2002-08-13 15:39                     ` Daniel Egger
2002-08-14  0:01                     ` Adam Kropelin
2002-08-12  2:54     ` Adam Kropelin
2002-08-12  3:40       ` Andrew Morton
2002-08-14  8:35 ` William Lee Irwin III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D5899DB.B087E40D@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=akropel1@rochester.rr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox