Re: A request to those people who want B-tree directories
Ard van Breemen (ard@cstmel.hobby.nl)
Sat, 28 Feb 1998 19:15:59 +0100 (MET)
On Fri, 27 Feb 1998, Dean Gaudet wrote:
> On Fri, 27 Feb 1998, Theodore Y. Ts'o wrote:
> > Another way of asking the question is --- of those people who complain
> > that it takes too long to look up a filename in a directory: while Linux
> > is looking up a filename in a large directory, is Linux disk bound or
> > CPU bound? If Linux is being disk bound, there are much better
> > solutions that don't necessarily require a B-tree.
>
> CPU bound. My reason for this hypothesis:
>
> - take a box w/512Mb of RAM, 2.1.62+, and run innd on it
>
> - watch the control newsgroup directory grow and grow
>
> - watch the system become so sluggish it feels like you're typing behind a
> 1000ms latency link
>
> - strace innd and watch open()s in the control directory take over 1s...
> which happen to be about the length of the lag you feel while typing
>
> No joke, the system had over 350Mb cached, it was definately not touching
> disk while accessing this directory. If it were touching disk I bet
> interactive performance would have been better.
May I contradict that interactive performance overhere usually is not
bothered by 100% cpu usage. But as paging increases (the interactive
processes paged or swapped out) due to heavy disk access (on a 2.0.30) the
system gets real sluggish with 98% idletime!
Doing a find > /dev/null usually kills any interactive performance
(unless heavily keeping interactive performance high by [enter] or ^L...),
but has a low cpu impact.
(of course, this is still 2.0.30...)
--
dec1: 6:54pm up 2 days, 20:03, 5 users, load average: 0.04, 0.05, 0.00
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu