Subject: Re: Linux 2.4.19-pre5
From: Ed Sweetman <ed.sweetman@wmich.edu>
To: Randy Hron <rwhron@earthlink.net>
Cc: Andrew Morton <akpm@zip.com.au>, linux-kernel@vger.kernel.org,
        marcelo@conectiva.com.br
In-Reply-To: <E16rQNU-00007G-00@gull.prod.itd.earthlink.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 30 Mar 2002 16:42:52 -0500
Message-Id: <1017524577.444.61.camel@psuedomode>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org

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