lkml.org 
[lkml]   [2001]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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