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- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:32 EST