From owner-freebsd-hackers Mon Feb 22 8:31:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 2BAE510FB2 for ; Mon, 22 Feb 1999 08:31:35 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id IAA16271; Mon, 22 Feb 1999 08:31:06 -0800 Date: Mon, 22 Feb 1999 08:31:05 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Doug Rabson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Check the code paths and look for B_ASYNC getting unset. I believe this > > is the correct patch. > > As I said before, the reads and writes in question are not delayed writes. > The reason I have a problem is that the i/o queue in the driver has grown > to an obscene length, increasing latency to unreasonable levels. Changing > the order of processing delayed writes is irrelavent to this problem. This isn't a new problem. When I did driver level clustering at Sun back in 1990, I was regularly seeing queue lengths in excess of 1000 for a 16MB memory Sparc2. > > > > > > I think the flag needs to be implemented in the driver. The driver should > > > check for the EXPEDITE flag and either maintain two queues for the two > > > possible priorities or place the buffer at the front of a single work > > > queue. > > > > This has some serious flaws. > > > > The first is, you have to get it right in more than one driver. This > > is really like the "wakeup" character change I did to the serial > > drivers to allow for unanticipated "hotchar" in binary only drivers > > from third parties, like E.T. Inc.. > > The driver changes would be small and the code can be arranged so that a > a driver doesn't have to change at all to keep functioning, just to > improve perceived performance. I think this would be a very good idea. This is exactly the kind of thing that HEAD OF QUEUE tags are designed for. I agree with Doug that this is not a requirement for continuing to run- just an improvement. And if you think about it, it's really only two drivers (scsi_da, wd). > > I've been looking at the UFS code all day, trying to make it set > B_EXPEDITE for all reads and writes for directories with only limited > success. > > I no longer think this is the correct solution and I am starting to try a > priority based scheme which uses a number similar to p->p_estcpu to > identify processes which are performing large amounts of i/o and to > penalise them by placing their subsequent i/o requests behind processes > with a lower i/o priority. > The only problem with this approach is not all I/O is or will be driven by a process. Let's say we port a new filesystem in that creates a *lot* of I/O via threads or wads of async r/w. Unless you start doing thread scheduling it's hard to figure out whome to penalize. I still would like to see a B_EXPEDITE (although B_PRIORITY seems a better name). Should we also be paying attention to B_ORDERED and should you consider doing buffer generations? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message