Messages in this thread | | | Date | Wed, 12 Aug 1998 07:07:48 +0200 (CEST) | From | "Michael L. Galbraith" <> | Subject | Re: 2.1.114 VFS code 5x slower than 2.0.33?!? (patch attached) |
| |
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
| |