A process doesn't use any memory after it's done; the memory is freed by the
kernel. If not, that would be a kernel bug.
Usually that's true, however there have been cases where the kernel has
bled memory like that the the blame was put on the process. So is
updatedb the cause, or just the trigger that exposes the bug? If you
really think that it's a kernel bug then feel free to reassign it.
But how have you determined that the memory is "in use"? It sounds to me
like you're misidentifying disk cache as "used" memory.
Nope. Disk cache is reported separately. Here is the results from
another run designed to reproduce the problem. It was run on an AthonXP
with 512MB of RAM, running up to date unstable and stock 2.6.17. I had
killed off everything except udev, syslog, init and the kernel processes:
# uname -a
Linux Barracuda 2.6.17-2-k7 #1 SMP Thu Aug 31 13:27:53 UTC 2006 i686
GNU/Linux
# ps ax
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 init [5]
2 ? S 0:00 [migration/0]
3 ? SN 0:00 [ksoftirqd/0]
4 ? S< 0:00 [events/0]
5 ? S< 0:00 [khelper]
6 ? S< 0:00 [kthread]
8 ? S< 0:00 [kblockd/0]
9 ? S< 0:00 [kacpid]
80 ? S< 0:00 [kseriod]
112 ? S 0:00 [pdflush]
113 ? S 0:00 [pdflush]
114 ? S 0:00 [kswapd0]
115 ? S< 0:00 [aio/0]
1502 ? S< 0:00 [khubd]
1847 ? S< 0:00 [kjournald]
1995 ? S<s 0:00 udevd --daemon
2784 ? S< 0:00 [kgameportd]
2830 ? S< 0:00 [kpsmoused]
2856 ? S< 0:00 [shpchpd]
3147 ? S< 0:00 [kmirrord]
3175 ? S< 0:00 [kjournald]
3696 ? Ss 0:00 /sbin/syslogd
3702 ? Ss 0:00 /sbin/klogd -x
4152 tty1 Ss 0:00 /bin/login --
5075 tty1 S 0:00 -bash
5398 tty1 R+ 0:00 ps ax
# free -m
total used free shared buffers cached
Mem: 504 69 435 0 5 49
-/+ buffers/cache: 14 490
Swap: 972 0 972
# updatedb
# free -m
total used free shared buffers cached
Mem: 504 313 191 0 108 52
-/+ buffers/cache: 152 352
Swap: 972 0 972
So the sort version is: After updatedb terminates (and buffers are
accounted for) the system is using an extra 138MB of RAM. This is more
than 1/4 of the RAM in the system, and the only way to get it back is to
reboot. All of which is completely unacceptable.
What is unusable about it?
Having no available memory makes it rather difficult to do any work on
the machine.
Other Notes:
I ran the above test on the same machine with a customised 2.6.17, and
received similar results. Running the same test on my AMD64 (albeit
with a full desktop environment running etc.) gets the following numbers:
before:
# free -m
total used free shared buffers cached
Mem: 1002 328 674 0 17 149
-/+ buffers/cache: 161 841
Swap: 1913 0 1913
after:
# free -m
total used free shared buffers cached
Mem: 1002 904 97 0 194 154
-/+ buffers/cache: 556 446
Swap: 1913 0 1913
so here I'm seeing a bleed of 395MB of RAM, or just shy of 40% of all of
the RAM in the system.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
