Re: [Lse-tech] Minutes from 9/7 Con Call

[Jens A. <ax...@su...>]

On Mon, Sep 17 2001, Jonathan Lahr wrote:
> > > I haven't studied the insertion code, but I believe a lot of the i/o 
> > > performance gain from this patch is due to the concurrency it allows 
> > > in __make_request.  On multiprocessor machines, i/o request submissions 
> > > can now be processed in parallel.
> > 
> > So you're just guessing now? You are attacking this problem from the
> > wrong angle.
> 
> 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.

Well duh

> > > It has been made extraordinarily clear that changes to 2.4 io_request_lock 
> > > locking are considered risky.  I am still exploring this problem only 
> > > because io_request_lock contention is showing up as a major i/o performance 
> > 
> > Changes in the order of what you presented are of course frowned upon,
> > since _they break stuff_.
> ...
> > Please start listening! You patch is broken, I've told you so many times
> > it's not even funny anymore.
> 
> The patch has been run on IDE and SCSI systems with heavy i/o loads without
> data corruption or deadlocks.  Describe in detail, not generalizations, how 
> it's broken. 

No, listen. You tell me why it's safe to remove io_request_lock in IDE
for instance. Read the code carefully and justify why it's safe. If you
can do that, then I can begin to trust that you know what you are doing
here.

> > I'm afraid that reducing io_request_lock scope in 2.4 will always be too
> > great a risk.
> 
> If the performance gain is high enough, some risk should be accepted.

Wrong

-- 
Jens Axboe