Perhaps there could be a 'dcache governor' which would keep track of the
number of new dcache dentries pre second and when it crosses a certian
(sysctl adjustable) threshold, starts marking the entries with a short
lifetime.. This way find wont make the dcache swell for nothing..
On Tue, 21 Apr 1998, Bill Metzenthen wrote:
>
> I've done a little more looking at the 'rusting' of the memory on my
> machine and I've reached a view:
>
> (1) the 'dcache' system is stealing memory which it doesn't release;
> effectively a memory leak,
> (2) the 'dcache' system appears to include a method for aging the memory
> it uses, presumably to allow it to be released, but this doesn't
> appear to work quite right,
> (3) there may be limits on the amount of leakage such that it is not
> noticed on machines with more than 8 Mbyte of RAM,
>
> I've included a small test script at the end of this message for people
> who might like to see if their machine appears to be affected. Here's
> the results for my machine:
>
> $ ./test-compile.sh ~sys
> Test gcc compile times.
> Linux version 2.1.96 (root@lorentz) (gcc version 2.8.1) #46 Thu Apr 16 09:57:31 EST 1998
> gcc takes 42.32 seconds before 'find'
> find /home/sys -print | wc --> find took 25.42 seconds
> 15541 15541 630856
> gcc takes 296.25 seconds after 'find'
> find /home/sys -print | wc --> find took 24.48 seconds
> 15541 15541 630856
> gcc takes 317.37 seconds after 120 second wait
>
> Notice that the performance of the two runs of 'find' are almost identical,
> indicating that it got negligible benefit from the caching. Also, there
> is no apparent recovery of memory after a 2 minute wait.
>
> My small testing script is below. It would be interesting to see if
> a machine with more than 8 Mbyte RAM is affected. I conjecture that
> a machine with 16 Mbyte would need to 'find' on a path with many
> tens of thousands of files.
>
> ----------------------- Start of test script ---------------------------
> #! /bin/bash
> # W. Metzenthen billm@suburbia.net, billm@melbpc.org.au
> #
> # Rust tester.
> # Call with a single parameter, a path containing lots of
> # files and directories (?).
> # e.g. /usr/src/linux has barely enough files (about 5000) to
> # show much effect on an 8 Mbyte machine, but a path with
> # 15000 files & directories gives pronounced results.
> #
>
> # I have more than one version of 'time' on my machine...
> time=/usr/local/bin/time
>
> if [ "$1" == "" ]
> then
> finddir=/
> else
> finddir="$1"
> fi
>
> echo "Test gcc compile times."
> cat /proc/version
>
> function timetest() {
> # Do what a kernel compile does for one particular file...
> $time --format="$1" \
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall \
> -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe \
> -fno-strength-reduce -m486 -DCPU=486 \
> -c -o /tmp/icmp.o icmp.c \
> 2>&1
> }
>
> cd /usr/src/linux/net/ipv4
>
> timetest "gcc takes %e seconds before 'find'"
>
> echo -n "find $finddir -print | wc --> "
> ($time --format="find took %e seconds" find $finddir -print | wc) 2>&1
>
> timetest "gcc takes %e seconds after 'find'"
>
> echo -n "find $finddir -print | wc --> "
> ($time --format="find took %e seconds" find $finddir -print | wc) 2>&1
>
> sleep 120
>
> timetest "gcc takes %e seconds after 120 second wait"
> ---------------------------- End of script -----------------------------
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu