Re: The cause of the "VM" performance problem with 2.4.X

[Jens Axboe <axboe@suse.de>]

On Tue, Aug 28 2001, Linus Torvalds wrote:
> >Abbreiated/stripped kernprof/gprof output:
> >------------------------------------------
> >
> >Each sample counts as 0.000976562 seconds.
> >  %   cumulative   self              self     total
> > time   seconds   seconds    calls  ms/call  ms/call  name
> > 39.46    224.65   224.65                             cg_record_arc
> > 16.40    318.00    93.34  6722992     0.01     0.02  getblk
> >  9.02    369.33    51.33 50673121     0.00     0.00  spin_lock_
> >  6.67    407.27    37.95  6722669     0.01     0.01  _make_request
> >  4.51    432.97    25.70 13445261     0.00     0.00  blk_get_queue
> >  2.61    447.83    14.86                             long_copy_user
> >  2.59    462.56    14.72                             mcount
> >  2.06    474.27    11.71                             cpu_idle
> 
> Now, while I don't worry about "getblk()" itself, the request stuff and
> blk_get_queue() _can_ be quite an issue even under non-mkfs load, so

blk_get_queue() is easy to 'fix', it grabs io_request_lock for no good
reason at all. I think this must have been a failed attempt to protect
switching of queues, however it's obviously very broken in this regard.
So in fact no skin is off our nose for just removing the io_request_lock
in that path. 2.5 will have it properly reference counted...

> And your lock profile certainly shows the io_request_lock as a _major_
> lock user, although I'm happy to see that contention seems to be
> reasonably low. Still, I'd bet that it is worth working on..

Sure is, the bio patches have not had io_request_lock in them for some
time.

-- 
Jens Axboe