Bug 151597
Summary: | /proc/<PID>/status shows unreasonable VmLib value | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | David Tonhofer <bughunt> |
Component: | kernel | Assignee: | Jason Baron <jbaron> |
Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.6 | CC: | davej, dejohnso, jbaron, joseph.breu, jwest, knoel, riel, tao |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-07 05:39:16 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
David Tonhofer
2005-03-20 16:30:41 UTC
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 |