On Wed, Mar 22 2000, Saxena, Deepak wrote:
>
> I've been working on the i2o_block driver for the last few months and
> in the proccess I've done some delving into the block I/O code of the
> kernel. I'm now trying to understand why io_request_lock exists.
> I understand that there needs to be some way of keeping the IO queues
> sane, but io_request_lock seems like overkill from my (possibly
> erroneous) understanding of the block layer of the kernel.
>
> Take the following situation. 2 cpus, two block devices (A & B) on
> different major numbers (hence separate request queues):
>
> CPU 0 gets an interrupt from block device A and gets to the
> stage where it is ready to call end_that_request_first()/last()
> to complete the request. Before it can do so, it grabs
> io_request_lock.
>
> Meanwhile, on CPU1, some application needs to read data from
> block dev B. That data is not in the buffer, so it needs to
> be read from the disk. The kernel gets to the point where it
> is ready to call request_fn for the device, and so it does
> a spin_lock(&io_request_lock). Since the lock is already
> acquired by CPU0, it waits for it to be released, even
> though they are on separate queues.
>
> This may not be the best example, but the point is that reqeusts
> to different devices on different CPUs will cause lots of spin
> lock contention. Is this what would happen or am I completely
> missunderstanding the implementation? Would it be better for
> performance to have a request_lock associated with each device's
> request_queue_t so blocking only occurs when the same queue might
> be touched by two CPUs? Please enlighten me if I've totally missed
> the mark on this.
While the above is true, maintaining sane device request queues is
not the only purpose the io_request_lock serves (unfortunately). Many
low level drives (SCSI was particularly bad) uses it as well, so
just replacing it with per request queue spin locks is not as
straight forward as it may seem.
It is a future plan, though.
-- * Jens Axboe <axboe@suse.de> * Linux CD-ROM Maintainer * http://www.kernel.dk- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:37 EST