Re: Linux 2.4.19-pre5

Ed Sweetman (
30 Mar 2002 16:42:52 -0500

On Sat, 2002-03-30 at 16:33, Randy Hron wrote:
> > > run. More importantly, read_latency2 drops max latency
> > > with 32-128 tiobench threads from 300-600+ seconds
> > > down to 2-8 seconds. (2.4.19-pre5 is still unfair
> > > to some read requests when threads >= 32)
> >
> > These numbers are surprising. The get_request starvation
> > change should have smoothed things out. Perhaps there's
> > something else going on, or it's not working right. If
> > you could please send me all the details to reproduce this
> > I'll take a look. Thanks.
> There was an improvement (reduction) in max latency
> during sequential _writes after get_request starvation
> went in. Tiobench didn't show an improvement for seq _read
> max latency though. read_latency2 makes the huge difference.
> The sequential read max latency walls for various trees looks like:
> tree # of threads
> rmap 128
> ac 128
> marcelo 32
> linus 64
> 2.5-akpm-everything >128
> 2.4 read latency2 >128
> I.E. tiobench with threads > the numbers above would probably
> give the impression the machine was locked up or frozen if your
> read request was the unlucky max. The average latencies are
> generally reasonable. It's the max, and % of high latency

Is that to say an ac branch (which uses rmap) can do the 128 but is
non-responsive? I sent a couple mails of my own preliminary runs and
the feel i got when running the test was absolutely no effect on
responsiveness even as the load hit 110. Of course this is with riel's
preempt patch for 2.4.19-pre4-ac3. I guess I'll try with threads = 256
just to see if this frozen feeling occurs in preempt kernels as well.
You dont seem to test them anywhere on your own site.

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