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.
- Deepak
-- Deepak Saxena - Software Engineer - Intelligent I/O Product Division Phone://480.554.9339 Mobile://602.790.0500 mailto:deepak.saxena@intel.comThe geeks shall inherit the earth
- 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