So you're theory here is that that all code that may be necessary to start I/O but could take a while should be done out of band. That's a reasonable response. The only problem is that you sometimes cannot easily tell if things like timeout driven recovery/restart can be used.
The basic difference here I would guess might be that if I needed to do, say, FC loop bringup or chip reprogramming after a reset in the isp driver, I should try and do it off of the worker thread so I neither slept nor polled from isp_start and always returned right away. I'll start thinking about that. -matt On Thu, 23 Oct 2003, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Matthew Jacob writes: > > >[1]: by 'sleep', I mean if I do *my* locking right, I should be able to > >yield the processor and wait for an event (an interrupt in this case). > > Not so when your device driver is entered through the devsw->strategy() > function, since that [cw]ould deadlock the entire disk-I/O system until > you return back up. > > Ideally, devsw->strategy() should just queue the request and return > immediately. In a world where context switches were free, scheduling > a task_queue to run foostart() (if necessary) would be the way to > do things. > > Most drivers call their own foostart() from strategy(), and as long > as foostart() does not go on long-term vacation, this is also OK, > poking a few registers, doing a bit of BUSDMA work is acceptable. > > But sleeping is not OK, mostly because a lot of sleeps may not > properly terminate in case of a memory shortage, and the way we > clear up a memory shortage is to page something out, and to page > something out we need to issue disk I/O, but somebody is holding > that hostage by sleeping in a driver... > > I will conceede that there are a certain small class of legitimate > sleeps that could be performed, unfortunately we can not automatically > tell an OK sleep from a not OK sleep, and therefore the decision > was to ban all sleeps, until such time as we had a case of something > that could not be (sensibly) done without the ability to sleep. > > I realize that in this case, you're sitting below CAM and scsi_??.c > and have very little say in what happens between devsw->strategy() > and your driver. > > As I read the original report, this is a case of error-handling. > Considering how long time error handling often takes and how > imperfect results one gets a lot of the time, error handling > should never strategy() sleep or take a long time, since that > will eliminates the chances that the system can flush dirty data > to other devices as part of a shutdown or panic. > > At some point soon, I plan to start measuring how much time > drivers spend in their strategy() routine and any offenders > will be put on notice because this is a brilliant way to hose > our overall system performance. I'm not going to set any > specific performance goal at this time, but I think we can > agree that more than one millisecond is way over the line. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
