Date: Tue, 23 Feb 1999 08:45:41 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <Pine.BSF.4.05.9902230836480.60339-100000@herring.nlsystems.com> In-Reply-To: <Pine.LNX.4.04.9902220824000.16179-100000@feral-gw>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Feb 1999, Matthew Jacob wrote: > > > > > > 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. Thats a lot of memory to be using in a 16Mb box. Was the machine still usable with this kind of i/o load? > > > > > > > > > > > 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. That could be a problem I suppose. > > 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? I'll keep fiddling with it and see if I can get a noticable improvement for directory operations. With a simple scheme like this the latency for e.g. an uncached small read could still be unbounded if there is a lot of async i/o happening. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.05.9902230836480.60339-100000>