Re: 2.1.114 VFS code 5x slower than 2.0.33?!? (patch attached)

Michael L. Galbraith (mikeg@weiden.de)
Wed, 12 Aug 1998 07:07:48 +0200 (CEST)


On Tue, 11 Aug 1998, Rik van Riel wrote:

> 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.
>

I bumped it to 13 to no effect.. it still gets 'stuck'. I haven't (yet)
found a reliable trigger. It did go wonkie immediately when I retreived
my mail while a du was running. Maybe coincidence.

-Mike

-
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