rwhron@earthlink.net wrote:
>
> ...
> Tiobench average of 3 runs
> --------------------------
> ...
> Random Writes
> Num Avg Maximum Lat% Lat% CPU
> Kernel Thr Rate (CPU%) Latency Latency >2s >10s Eff
> ----------------- --- ------------------------------------------------------
> ...
> 2.4.18-rc2 128 0.67 1.87% 1.334 777.23 0.00000 0.00000 36
> 2.4.18-rc2-jam1 128 0.80 5.72% 0.190 3.68 0.00000 0.00000 14
> 2.4.18rc2aa2 128 0.61 1.39% 61.796 72674.58 0.32761 0.32761 44
>
> ...
Holy cow! Are you sure these numbers are right?
The increased throughput will be thanks to the boosted request
queue size.
The (greatly) increased CPU load will also be due to browsing the eight-times
larger request queue. Plus we browse it a bit more than we used to.
The improvement in worst-case latency in both -aa and -jam will
be due to the FIFO wait for requests.
But improvement by a factor of 20,000 sounds a little excessive :)
And a maximum latency of three milliseconds would seem to indicate
that the benchmark is *never* waiting on disk seek, and that
perhaps the request queue is simply never filling up. But that
doesn't make sense.
What does the "latency" actually mean? Is it the time spent
in the kernel to issue a write(2)?
Something funny is happening, I suspect. Guess I should go
look at tiobench...
-
-
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/
This archive was generated by hypermail 2b29 : Sat Feb 23 2002 - 21:00:39 EST