---876492614-140791035-902844813=:1068
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.3.96.980811213643.8774I@mirkwood.dummy.home>
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/ |
+-------------------------------------------------------------------+
---876492614-140791035-902844813=:1068--
-
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