> I don't see any speed difference with the patch, but I did notice something
> that looks very strange. Please bear with me, as it's difficult to describe
> that which you only understand little pieces of. Notice CALLS below and
> remember the previous report (293168 for profiling du -s /usr/src/linux).
>
> 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
>
> TIME% USECS-TOTAL AVG-USECS CALLS ADDRESS FUNCTION
> profa: 2.9294% 15112.17 0.85 17711 c0147247 ext2_check_dir_entry
> profb: 1.4757% 6221.63 0.87 7129 c0147247 ext2_check_dir_entry
> profc: 3.9282% 247488.82 0.84 294418 c0147247 ext2_check_dir_entry
> profd: 16.7667% 236475.48 0.84 280503 c0147247 ext2_check_dir_entry
> profe: 14.9596% 234952.73 0.84 279692 c0147247 ext2_check_dir_entry
> proff: 19.6429% 232544.38 0.84 277482 c0147247 ext2_check_dir_entry
>
> The test order is the same as above. The only difference is that I putzed
> around longer in the huge directory. This time, it went straight to max
> and stayed there with no stops in between.
Hmm, very strange. If I understand correctly, something is "breaking" and causing a
huge increase in the number of times ext2_check_dir_entry gets called. So it's not
that the routine is particularly slow, but rather it's getting called way too many
times.
I'll need to do a little more research on this one ... let me know if you get any
more clues tot he puzzle.
Regards,
Bill
-
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