Messages in this thread | | | From | "Saxena, Deepak" <> | Subject | io_request_lock and system performance (can it be replaced?) | Date | Wed, 22 Mar 2000 13:54:48 -0800 |
| |
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.com
The 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/
| |