Date: Wed, 8 Mar 95 9:33:49 MST From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-bugs@FreeBSD.org Subject: Re: QIC-80 problem Message-ID: <9503081633.AA00803@cs.weber.edu> In-Reply-To: <199503080113.LAA30812@godzilla.zeta.org.au> from "Bruce Evans" at Mar 8, 95 11:13:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I recently noticed that the standard timer code doesn't guarantee any > upper bounds for timeouts. softclock() runs at a lower priority than > all hardware interrupts. It is possible for a fast device on a slow > interface to keep the system busy handling interrupts so that > softclock() never runs. A fast EIDE drive using the old IDE interface > can probably do this (unless the system isn't programmed well enough to > keep the data streaming :-]). > > The one shot timer would have to be handled at a higher priority than > softclock() or its resolution would be lost. It wouldn't necessarily > work to use the same priority as the device that requested the timeout. > The ft priority would have to be higher than the wd priority to avoid > the above problem. This would require large reorganizations because > the ft priority and the wd priority are currently identical (bio). Right; putting the timer at a high priority is one of the things which is needed. Putting the floppy at nearly the highest priority is only logical, given that it has no buffers. A good example of "the right" priority levels is available by examining the SMP SCO Xenix (Corrollary version). Basically, any interface that doesn't have buffers on its I/O should be higher priority that any interface that does. I'd be tempted to put the floppy at just below the timer priority itself, and multithread things at a real low granularity -- ideally the buzz-loops in device drivers should be timer scheduled events, and any other approach to scheduling will have either everything running at the timer priority or will require helper processes like "update" to make things work. A real gross hack. When you consider wd vs ft/fd priority, you also need to consider that much of the I/O wait in the user program is reading from, for instance, the wd (or some other disk driver) to do the tape write in the first place. Unfortunately, I don't know of a software method of detecting the most offensive wd interface, an IDE without buffer chips on it... the only thing I can thing of is trying to run BSD and having it fail on you. 8-). The first thing one should do, probably, is to get the floppy tape reliability divorced from the need for a program in user space to get its quantum for it to be able to operate correctly, or any time anyone hits 90%+ on system load the thing is going to fail for sure. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503081633.AA00803>