Date: Mon, 22 Feb 1999 09:22:48 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Terry Lambert <tlambert@primenet.com> Cc: dillon@apollo.backplane.com, freebsd-hackers@freebsd.org Subject: Re: Panic in FFS/4.0 as of yesterday Message-ID: <Pine.BSF.4.05.9902220915100.82049-100000@herring.nlsystems.com> In-Reply-To: <199902220534.WAA01171@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Feb 1999, Terry Lambert wrote: > > > > I think promoting directory writes (and directory reads probably) might be > > > > the simplest solution. > > > > > > OK, here's code to add the ability to expedite placement of async > > > writes. It' doesn't insert them in order behind other expedited > > > writes, so it turns the expedited stuff LIFO. This is probably > > > suboptimal, but can't happen in dependent operations, so what the > > > heck... > > > > > > When you use the code, be sure to *not* set the flag if soft updates > > > are in effect (I think that's a caller issue, not a callee issue, since > > > it would complicate the bdwrite code, probably unacceptably. > > > > I don't think this will do the job at all. The buffers in question are > > not delayed writes, so all this patch will do is change the order of the > > LOCKED and LRU lists, probably pessimising the reuse of those buffers. > > 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. > > > 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. > > The second is that the lock cascade occurs because of locked vnodes > over an operation queued through this code, and only completion > notification will get rid of the lock. > > The third is that, however you do it, it needs to be harmless to > disk integrity in the soft updates and standard mount cases. The > standard mount case comes for free, by not using the B_ASYNC flag; > but the soft updates case is harder. You won't be able to add an > assert check at the queue-to-driver level to make sure the code is > right, since the buffer is no longer associated with the structure > that contains the soft dependency active/inactive information. > > Look at the cases where the I/O call is actually made in the UFS code, > and trace the function calls down. I'm willing to be wrong. 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. -- 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.9902220915100.82049-100000>