How is "find" going to be fixed in 2.3? This is interesting to me as
I'm writing an optimised replacement for "find" the program.
> 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.
I assume you mean "find" the program. Do you?
That has considerable CPU overhead as well as I/O because it churns the
dcache and icache constantly, so the kernel spends a fair amount of time
making decisions about what it can prune. I've noticed the kernel can
get into a state where it spends more time doing this, or a state where
it spends less time doing it, but I've no consistent way to trigger
either state.
-- Jamie
>
> 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.
>
> 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.
>
>
> - --
> -----==- |
> ----==-- _ |
> ---==---(_)__ __ ____ __ Marc Lehmann +--
> --==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
> -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
> The choice of a GNU generation |
> |
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
-
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/