From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910
Description of problem:
The machine is a two-processor EM64T Xeon with 2.6.9-5.0.3.ELsmp
The display for 'VmLib' (VM size of libraries)
in /proc/<PID>/status seems to be a bit on the
large side for a MySQL process (actually the thread group leader if I
understand correctly). This is the only 'status' that has this problem
all the other show values that are reasonable:
State: S (sleeping)
Uid: 101 101 101 101
Gid: 101 101 101 101
VmSize: 745184 kB
VmLck: 0 kB
VmRSS: 334584 kB
VmData: 716632 kB
VmStk: 32 kB
VmExe: 3646 kB
VmLib: 18446744073708325478 kB <---- 0xFFFF'FFFF'FFED'4A66
StaBrk: 008b1000 kB
Brk: 0157a000 kB
StaStk: 7fbfffefd0 kB
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: VmLib shows unreasonable value.
Expected Results: VmLib should show something reasonable.
That looks like a negative value to me, with the statistic somehow underflowing.
From task_mem() in fs/proc/proc_mmu.c:
char *task_mem(struct mm_struct *mm, char *buffer)
unsigned long data, text, lib;
data = mm->total_vm - mm->shared_vm - mm->stack_vm;
text = (mm->end_code - mm->start_code) >> 10;
lib = (mm->exec_vm << (PAGE_SHIFT-10)) - text;
It appears that lib is generated by subtracting text from exec_vm.
In __vm_stat_account() in mm/mmap.c:
if (flags & VM_EXEC)
mm->exec_vm += pages;
However, for backwards compatibility, the i386 architecture emulation code
forces exec rights on a VM that is mapped with just VM_READ. That means that
the text section could end up larger than what is counted in the exec_vm statistic.
This results in the statistics being printed wrong for 32 bit apps that do not
use PROT_EXEC in their mmap calls, but should otherwise be harmless.
Hi, original poster here.
The error is certainly harmless we never had a problem with the large values.
Problem still occurs on the latest update of RH4.
Note that the MySQL process shown above is a 64-bit executable (ELF 64-bit LSB
executable, AMD x86-64) compiled on the 64-bit machine, so this is not
restricted to 32-bit processes.
Can you confirm that the RAM used/free reported by 'free' is mis-reported as well?
In our case, I have a AMD 64bit box with 32GB of RAM running memcached and mysqld. Those processes combined use <6GB of RAM, but the OS is reported >30GB utilized.
/proc/<mysqld pid>/status reports VmLib for MySQL is:
VmLib: 18446744073709543776 kB
I just checked that this occurs on 2.6.9-78.0.5.ELsmp (RH 4.7) by running
LIST=`find /proc -name status`
for I in $LIST; do echo $I; grep VmLib $I; done
The fact that the OS says that 30GB are utilized should be normal - Linux uses the RAM as cache as far as possible.
"free" then shows something near 0, like this:
total used free shared buffers cached
Mem: 5071004 4875856 195148 0 740968 2266892
-/+ buffers/cache: 1867996 3203008
Swap: 3080184 180 3080004
Try my script at http://misato.m-plify.net/memory to print a nice tree representation of the memory used (hopefully correct).
Here's what I get when running the memory script. Something is overflowing here...
Total physical memory available
|--Swap memory 1077469184
| |--Free: 1077239808
| `--Used: 229376
`--Dynamic memory: 33730404352
|| |--Kernel slab: 706445312
|| | `--Page tables: 17686528
|| `--Non-kernel: 32862777344
|| |--Caching: 1278234624
|| | |--Buffer cache: 572407808
|| | |--Page cache: 705826816
|| | | |--Mapped: 6656565248
|| | | | |--Dirty: 143360
|| | | | |--Writeback: 0
|| | | | `--Clean: 6656421888
|| | | `--Copied: -5950738432
|| | `--Swapcached: 0
|| `--User processes: 31584542720
|| `--Sum RSS: 6790004736
||--Inactive pages: 1548386304
||--Active pages: 31273738240
|`--Other pages: 908279808
|--Low memory: 33730404352
| |--Free: 161181696
| `--Used: 33569222656
`--High memory: 0
Ok, don't worry about the overflow; I must have interpreted "copied" wrongly.
What is of interest to you is -- why the large difference between
`--User processes: 31584542720
`--Sum RSS: 6790004736
Unfortunately I don't know. But as this has nothing to do with this bug, the discussion should be taken to the General Red Hat Discussion List [http://www.redhat.com/mailman/listinfo] or maybe the Linux kernel list [http://www.kernel.org/pub/linux/docs/lkml/].