Dimitris,
This is very helpful. I am re-running the I/O tests this evening. I
will post the numbers for all the runs for folks to look at. Had an
annoying Ooops on 2.2.15 that has been fixed that got me sidetracked for
a couple of hours. I will post numbers as soon as I have them.
Jeff
Dimitris Michailidis wrote:
>
> From: Dimitris Michailidis <dimitris@engr.sgi.com>
> Date: 11 Apr 2000 16:25:44 -0700
> In-Reply-To: "Jeff V. Merkey"'s message of "11 Apr 2000 15:27:15 -0700"
> Message-ID: <6yrg0ssrzif.fsf@darkside.engr.sgi.com>
> Lines: 30
> X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"
>
> "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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:17 EST