[lkml]   [2003]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BENCHMARK] 2.5.59-mm7 with contest
    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:32    [W:0.019 / U:14.116 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site