From: Jonathan L. <la...@us...> - 2001-09-17 19:42:50
|
Alan Cox [al...@lx...] wrote: > > Allowing multiple processors to concurrently submit i/o requests to > > multiple device queues rather than unnecessarily serializing all i/o > > request submissions is generally a good idea for performance. > > Except when the layers rely on the same lock for multiple purposes. The > io_request lock isnt just a queue lock, its internal locking in some drivers > and since we sometimes use it for layered drivers (ataraid, md, lvm..) its > asking for problems. I agree it is clear that io_request_lock is used for multiple purposes by block i/o, scsi-mid, and drivers. One purpose for io_request_lock is to protect the request queue (queue_head). The patch changes protection of the queue by having __make_request, the producer of the queue, and scsi_request_fn, the consumer of the queue, use q->queue_lock instead of io_request_lock. The scope of io_request_lock is left intact elsewhere except for scsi_request_fn, in which case is it increased. This leaves other existing io_request_lock serialization in place. So, unless a driver accesses the request queue without taking q->queue_lock, queue integrity is protected. > > If the performance gain is high enough, some risk should be accepted. > > See http://marc.theaimsgroup.com/?l=lse-tech&m=100017134609802&w=2. > > The best way to handle such things is to shove them in early 2.5, then > back port if they prove ok In this particular case, that not possible since Jens is removing io_request_lock altogether in 2.5 which I think is a good idea after studying it's use in 2.4. -- Jonathan Lahr IBM Linux Technology Center Beaverton, Oregon la...@us... 503-578-3385 |