Re: [2.1.3(56)] Time trials on an ASUS P166 w/ DMA2'd IBM DeskStar

David S. Miller (
Thu, 24 Apr 1997 17:07:15 -0400

Date: Thu, 24 Apr 1997 15:18:40 -0400
From: Aaron Tiensivu <>

Each was only run once, so I suppose more 'time trials' might give
some more data points of comparison, but it looks like not much has
changed performance-wise.

One thing which will be faster in 2.1.36 is something like the
following, go into a fully built kernel tree and go:

cat `find . -type f` >/dev/null

A second invocation should be near instantaneous, depending upon how
much ram you have. I just improved the inode LRU scheme slightly, but
not by much. The problem with aging inodes is that if you zap an
inode and reuse it for something else, you risk tossing a considerable
number of pages from the page cache (these pages are freed entirely,
because since the inode is re-used there is no way to "tag" them with
the inode they were previously assosciated with, it would be less of
an issue if we could re-connect these page cache entires to the
original inode should it get created once again)

Inodes are really difficult to tune correctly, I'm investigating some
schemes in the mean time which might help out.

I did make dcache hashing and lookup a bit faster in 2.1.36, however I
did nothing about the size of the LRU queues or the aging scheme at
all, so I really don't expect it to handle thrashing any better than
before ;-) Thomas Schoebel has been exchanging some ideas with me to
make the dcache perform better and be more extendable, we'll be
working on eventual merge of all his ideas into 2.1.x

The buffer cache needs some work still, that code is a mess, so this
is one of the areas I'll be working on cleanups for...

Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, /_____________/ / // /_/ ><