Messages in this thread |  | | | Date | Tue, 11 Aug 1998 21:39:24 +0200 (CEST) | | From | Rik van Riel <> | | Subject | Re: 2.1.114 VFS code 5x slower than 2.0.33?!? (patch attached) |
| |
On Tue, 11 Aug 1998, Michael L. Galbraith wrote:
> profiling du -s linux: > > TIME% USECS-TOTAL AVG-USECS CALLS ADDRESS FUNCTION > prof1: 3.5108% 8167.04 0.85 9618 c0147244 ext2_check_dir_entry > prof2: 2.6960% 6102.58 0.86 7065 c0147244 ext2_check_dir_entry > prof3: 3.8586% 243933.56 0.83 294344 c0147244 ext2_check_dir_entry > prof4: 7.9671% 63744.33 0.85 74996 c0147244 ext2_check_dir_entry > > prof1 is primed cache after fresh boot. > prof2 is re-prime and repeat. > prof3 is after putzing around in the huge test directory. (whack cache) > prof4 is re-prime and repeat. > > I repeated prof4 many times.. consistent at ~75000 now. (hmm) Checked
Looks like we need more hash bits... After the cache priming, prof3 simply clears out the dcache in (LRU?) order and allocates the entries in the order the entries are freed.
After that, the hashing scheme is pretty much disturbed and we need far more time to look up entries.
Of course, this is wild speculation as I don't know much of the internals of the dcache system... I just think I remember some succes message of someone increasing HASH_BITS a few months ago :)
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+ |  |