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
-
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 : Wed Nov 07 2001 - 21:00:25 EST