> On Mon, Aug 09, 1999 at 11:28:03PM +0200, Hermann Schichl <herman@esi.ac.at> wrote:
> > >
> > This is not a situation of Linux (IMHO) but one of UNIX. Most Unices
> > show this behaviour. Probably if you try ls -fR, times should go linearly
> > with directory size.
>
> As I said, this has nothing to do with ext2 being slow with large directories
> (or any fs being slow).
O(n^2) - both ext2 and isofs do linear search in directories.
> I would _not_ mind "find" being slow, esp. since this is going to be fixed
> in 2.3.
>
> I _do_ mind my whole system getting slow just because some background
> process runs find. And yes, the whole system gets slow and _very_
> sluggishly.
Have you profiled it?
> This happens only while scanning large directories. My "theory du jour"
> is that the dcache operations are single-cpu and - in this case - very time
> consuming.
BS. The only places where it would affect the things are shrink_dcache_parent()
and d_invalidate(). Not going to happen with normal find(1) stuff.
Besides, solution should not be SMP-only.
> That (or something similar, as my theory is most probably wrong) would
> explain why my dual cpu system gets so sluggishly while just doing "find",
> which should be very i/o intensive but nothing else.
What arguments are you passing to find(1)?
-
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.tux.org/lkml/