Messages in this thread | | | Date | Wed, 29 Aug 2001 10:22:16 +0200 | From | Jens Axboe <> | Subject | Re: The cause of the "VM" performance problem with 2.4.X |
| |
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/
| |