Re: [Ext2-devel] disk throughput

[Mike Fedyk <mfedyk@matchmail.com>]

On Sun, Nov 04, 2001 at 07:45:21PM -0800, Andrew Morton wrote:
> Mike Fedyk wrote:
> > What settings are you suggesting?  The 2.4 elevator queue size is an
> > order of magnatide larger than 2.2...
> 
> The default number of requests is 128.    This is in fact quite ample AS
> LONG AS the filesystem is feeding decent amounts of reasonably localised
> stuff into the request layer, and isn't stopping for reads all the time.
> ext2 and the VFS are not.  But I suspect that with the ialloc.c change,
> disk readahead is covering up for it.
>

Hmm...

> The meaning of the parameter to elvtune is a complete mystery, and the
> code is uncommented crud (tautology).  So I just used -r20000 -w20000.
> 

I saw somewhere that Andrea Acrangeli wrote it... Maybe he can help?

> This was based on observing the request queue dynamics.  We frequently
> fail to merge requests which really should be merged regardless of
> latency.  Bumping the elvtune settings fixed it all.  But once the
> fs starts writing data out contiguously it's all academic.
> 

I have had much improved interactive performance with -r 333 -w 1000, or
even -r 100 -w 300...

Setting it down to -r 0 -w 0 caused several processes (in a -j5 kernel
compile) to start waiting for disk...

> > >
> > > The time to create 100,000 4k files (10 per directory) has fallen
> > > from 3:09 (3min 9second) down to 0:30.  A six-fold speedup.
> > >
> > 
> > Nice!
> 
> Well.  I got to choose the benchmark.
>

Yep, but I'm sure the diffing two trees test will will get your patch
noticed... ;)

How do the numbers look for ext2 mounted -o sync?

> > My God!  I'm no kernel hacker, but I would think the first thing you would
> > want to do is keep similar data (in this case similar because of proximity
> > in the dir tree) as close as possible to reduce seeking...
> 
> Sure.  ext2 goes to great lengths to avoid intra-file fragmentation,
> and then goes and adds its own inter-file fragmentation.
> 
> It's worse on larger partitons, because they have more of the 128 meg
> block groups.
>

Yep.

Do you think that more (and thus, smaller) block groups would help for the
larger partitions?  

> > Is there any chance that this will go into ext3 too?
> > 
> 
> If it goes in ext2, yes.  

Great!

>Depends on what the ext2 gods say - there
> may be some deep design issue I'm missing here.
> 
Yes, let's see what they say. :)

Mike