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: Name: mysqld State: S (sleeping) SleepAVG: 98% Tgid: 8123 Pid: 8123 PPid: 8095 TracerPid: 0 Uid: 101 101 101 101 Gid: 101 101 101 101 FDSize: 256 Groups: 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 Threads: 71 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000085007 SigIgn: 0000000000001006 SigCgt: 00000001800064e9 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: n/a Actual Results: VmLib shows unreasonable value. Expected Results: VmLib should show something reasonable. Additional info:
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 -Joe
Hi, 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 Joseph, 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 |||--Free: 161181696 ||`--Used: 33569222656 || |--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 |--Free: 0 `--Used: 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/]. Best regards, DT