"Jeff V. Merkey" <jmerkey@timpanogas.com> writes:
> I tries runs of 500 buffers, 1000 buffers, 2000 buffers, 3000 buffers,
> and 4000 buffers.
>
> And the winners are!
>
> 1. ll_rw_blk (and add_request/make_request) (oink, oink..... oink,
> oink ... rooting around down in the hardware -- I think it's looking for
> truffles)
I suspect that add_request/make_request are not the real culprits here. My
experience with heavy disk I/O tests is that the bottleneck is usually
__get_request_wait(), but that executes with interrupts off so profiling
charges the callers instead. Here's an excerpt from a call graph profile
(kernel is 99-pre3):
0.87 1.19 20662/20662 generic_make_request [22]
[51] 0.5 0.87 1.19 20662 __get_request_wait [51]
1.15 0.04 200799/379645 schedule [47]
As you can see processes sleep/wake_up a lot in __get_request_wait and
generate more than half of all the scheduling activity. This is despite the
wake_one, and actually having all processes wake up simultaneously doesn't
make things all that worse (increases calls to schedule() by about 20% in my
case). The real bottleneck under disk I/O load is the single request array,
IMO.
-- Dimitris Michailidis dimitris@engr.sgi.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/