On Tue, 11 Dec 2007, Krzysztof Oledzki wrote:
On Wed, 5 Dec 2007, Krzysztof Oledzki wrote:
On Wed, 5 Dec 2007, [email protected] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9182
------- Comment #20 from [email protected] 2007-12-05 13:37 -------
Please monitor the "Dirty:" record in /proc/meminfo. Is it slowly rising
and never falling?
It is slowly rising with respect to a small fluctuation caused by a current
load.
Does it then fall if you run /bin/sync?
Only a little, by ~1-2MB like in a normal system. But it is not able to
fall below a local minimum. So, after a first sync it does not fall more
with additional synces.
Compile up usemem.c from
http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz and run
usemem -m <N>
where N is the number of megabytes whcih that machine has.
It has 2GB but:
# ./usemem -m 1662 ; echo $?
0
# ./usemem -m 1663 ; echo $?
./usemem: mmap failed: Cannot allocate memory
1
Did this cause /proc/meminfo:Dirty to fall?
No.
OK, I booted a kernel without 2:2 memsplit but instead with a standard
3.1:0.9 and even without highmem. So, now I have ~900MB and I am able to set
-m to the number of megabytes which themachine has. However, usemem still
does does not cause dirty memory usage to fall. :(
OK, I can confirm that this is a regression from 2.6.18 where it works OK:
ole@cougar:~$ uname -r
2.6.18.8
ole@cougar:~$ uptime;grep Dirt /proc/meminfo;sync;sleep 2;sync;sleep 1;sync;grep Dirt /proc/meminfo
14:21:53 up 1:00, 1 user, load average: 0.23, 0.36, 0.35
Dirty: 376 kB
Dirty: 0 kB
It seems that this leak also exists in my other system as even after many
synces number of dirty pages are still >> 0, but this the only one where
it is so critical and at the same time - so easy to reproduce.
Best regards,
Krzysztof Olędzki
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
