Re: [BENCHMARK] 2.5.59-mm7 with contest

[Con Kolivas <conman@kolivas.net>]

On Saturday 01 Feb 2003 11:37 am, Nick Piggin wrote:
> Con Kolivas wrote:
> >Seems the fix for "reads starves everything" works. Affected the tar loads
> >too?
>
> Yes, at the cost of throughput, however for now it is probably
> the best way to go. Hopefully anticipatory scheduling will provide
> as good or better kernel compile times and better throughput.
>
> Con, tell me, are "Loads" normalised to the time they run for?
> Is it possible to get a finer grain result for the load tests?

No, the load is the absolute number of times the load successfully completed. 
We battled with the code for a while to see if there were ways to get more 
accurate load numbers but if you write a 256Mb file you can only tell if it 
completes the write or not; not how much has been written when you stop the 
write. Same goes with read etc. The load rate is a more meaningful number but 
we haven't gotten around to implementing that in the result presentation.

Load rate would be:

loads / ( load_compile_time - no_load_compile_time )

because basically if the load compile time is longer, more loads are 
completed. Most of the time the loads happen at the same rate, but if the 
load rate was different it would be a more significant result than just a 
scheduling balance change which is why load rate would be a useful addition.

Con