From owner-freebsd-hackers Fri Oct 12 15:53:24 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id EFB4337B407; Fri, 12 Oct 2001 15:53:15 -0700 (PDT) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id f9CMqiH71836; Fri, 12 Oct 2001 15:52:44 -0700 (PDT) (envelope-from jkh@freebsd.org) To: mjacob@feral.com Cc: jrossiter@symantec.com, sos@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Severe I/O Problems In-Reply-To: <20011012152458.E73308-100000@wonky.feral.com> References: <20011012152458.E73308-100000@wonky.feral.com> X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011012155244Q.jkh@freebsd.org> Date: Fri, 12 Oct 2001 15:52:44 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 127 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Erm, this would make this the first report of "interference effects" I've ever heard, certainly. Doesn't make it untrue, just subject to a bit more initial skepticism. Is this truly the only variable that's changing? Are we sure that the drives in question aren't simply broken in some way and manifesting this behavior as an aberration among IDE drives? Have different manufacturer's units been involved in cross-testing? Thanks. - Jordan > > 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 > > > > com> cc: > > 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