Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Oct 2001 15:26:07 -0700 (PDT)
From:      Matthew Jacob <mjacob@feral.com>
To:        Jay Rossiter <jrossiter@symantec.com>, <sos@freebsd.org>, Jordan Hubbard <jkh@freebsd.org>
Cc:        <freebsd-hackers@freebsd.org>
Subject:   Re: Severe I/O Problems
Message-ID:  <20011012152458.E73308-100000@wonky.feral.com>
In-Reply-To: <OF93C7F686.4FAB3595-ON88256AE3.007A49DB@symantec.com>

next in thread | previous in thread | raw e-mail | index | archive | help

Interesting. If this bears out, what this tells me is that in some cases
enabling write cacheing on ATAs is good, but in other cases, bad (probably
provides interference effects).

Soren? Jordan?

-matt


On Fri, 12 Oct 2001, Jay Rossiter wrote:

>
>
>      This does seem to be doing some good.    The beginning of the test run
> is hovering ~30% CPU.   I'll have to wait until it finished before I can
> see if it effected the overall time, though.
>
>      Something else that I forgot to mention, is that yesterday I did a
> profiled run, and the code-time between the two scenarios differs by less
> than ten minutes.  (The in-memory files vs. on disk files)  The disk files
> just take infinitely longer to do anything to.
>
>
>
>
>
>                     Matthew Jacob
>                     <mjacob@feral.       To:     Jay Rossiter <jrossiter@symantec.com>
>                     com>                 cc:     <freebsd-hackers@FreeBSD.ORG>
>                                          Subject:     Re: Severe I/O Problems
>                     10/12/2001
>                     02:57 PM
>                     Please respond
>                     to mjacob
>
>
>
>
>
>
>
> Hmm. Interesting. What's the state of the ATA write caching bit?
> (sysctl hw.ata.wc)?
>
> If it is set to 1, try setting it to 0 in /boot/loader.conf
> (e.g., add
>
> hw.ata.wc=0
>
> )
>
> to /boot/loader.conf
>
> -matt
>
>
> On Fri, 12 Oct 2001, Jay Rossiter wrote:
>
> >
> >      Someone on -questions recommended that I forward this over here for
> > you guys to look at.  (I'm not subbed to this list)
> >
> > There appear to be a lot of changes that went into the filesystem and I/O
> > code between 4.3 and 4.4.  A little over a week ago I upgraded my 4.3 box
> > to 4.4-STABLE and immediately I started having I/O slowdown.  I do
> > development and QA on a program that is very I/O bound, but the changes
> > between 4.3 and 4.4 aren't small enough that I can ignore them.
> >
> > A few statistics:
> >
> > BSD, P4 1.4GHz, ATA100 drives
> > - Normal test run on 4.3 was taking ~3 hours.
> > - Normal test run on 4.4 is taking 15-16 hours.
> >
> > P3-800, ATA66 drives, SuSE Linux 7.1:
> > - Normal test run takes ~4.5 hours.
> >
> > UltraSparc 10, Solaris 8, ATA66 drives:
> > - Normal test run takes ~6 hours.
> >
> > As you can see, this jump was just phenomenal.
> >
> > I can run these tests on a custom 'ramdrive' and the test run takes 1.5
> > hours on BSD.  ~4 on Solaris, ~2.5 on Linux.
> >
> > Even the RS/6000 I test AIX 4.3 with doesn't take this long, though I
> don't
> > have statistics for it.
> >
> > It appears that the app gets stuck switching between the getblk and biowr
> > states in top and ps, and very rarely does it take more than 5% of the
> CPU.
> > On all other OS's, and even on 4.3, this app was pegging the CPU while it
> > did its work.
> >
> > Basically.. this all comes down to "What the hell is going on here?!" and
> > "Are there plans to fix it and did anyone even know there was a problem?"
> >
> > ---
> > Jay Rossiter                             503-614-7917
> > QA Engineer, Test Lead
> > Symantec Corp.
> >
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-hackers" in the body of the message
> >
>
>
>
>
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011012152458.E73308-100000>