Re: 2.1.115 is not slower than 2.0.34

Andries.Brouwer@cwi.nl
Sat, 15 Aug 1998 22:28:18 +0200 (MET DST)


From andi@zero.aec.at Sat Aug 15 14:35:30 1998

Could you do the same test again with this patch applied? It should
tune the dcache even more, with minimal changes and also helps against
memory fragmentation.

Hmm. Probably it would be a bad idea if I did.
Misleading results are worse than no results.

(Tuning cache is a complicated and delicate matter,
and it takes a nontrivial amount of time to develop
a theory about typical usage patterns. Things that work
very well in one situation are the worst one can do in another.
I have no theory about the dcache right now, so experimenting
would just yield meaningless, uninterpretable numbers.

What I did was something much simpler. There is a code path
that is executed millions of times and I reduced that to
thousands of times - not by improving the cache, but just
by testing each directory entry once instead of a thousand times
for errors.
Clearly that is going to improve things, so the question only
was whether the improvement is noticeable. In my tests it is.

The cache only means that I must be careful interpreting my results:
after one iteration of the test no more disk I/O is required.
After one or two iterations all filenames are in the dcache
and no find_entry() is required anymore. These effects are clearly
visible. But my tests can in no way be regarded as a test of the dcache,
and cannot easily be changed into such a test.)

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html