[lkml]   [2001]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: io_request_lock/queue_lock patch
On Tue, Sep 04 2001, Jonathan Lahr wrote:
> > You are now browsing the request list without agreeing on what lock
> > is
> > being held -- what happens to drivers assuming that io_request_lock
> > protects the list? Boom. For 2.4 we simply cannot afford to muck
> > around
> > with this, it's jsut too dangerous. For 2.5 I already completely
> > removed
> > the io_request_lock (also helps to catch references to it from
> > drivers).
> In this patch, io_request_lock and queue_lock are both acquired in
> generic_unplug_device, so request_fn invocations protect request queue
> integrity. __make_request acquires queue_lock instead of
> io_request_lock
> thus protecting queue integrity while allowing greater concurrency.

You fixed SCSI for q->queue_head usage, that part looks ok. The low
level call backs are a much bigger mess though. And you broke IDE,
cciss, cpqarray, DAC960, etc etc in the process.

> Nevertheless, I understand your unwillingness to change locking as
> pervasive as io_request_lock. Such changes would of course involve
> risk. I am simply trying to improve 2.4 i/o performance, since 2.4
> could have a long time left to live.

I can certainly understand that, but I really hope you see what I mean
that we cannot change this locking now.

Jens Axboe

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.085 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site