Re: [PATCHSET] Linux 2.4.18-rc3-jam1

[Andrew Morton <akpm@zip.com.au>]

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...

-