Messages in this thread | | | Date | Wed, 11 May 2011 17:30:14 -0500 | From | Russ Anderson <> | Subject | [bug] mm: hugepages can cause negative commitlimit |
| |
If the total size of hugepages allocated on a system is over half of the total memory size, commitlimit becomes a negative number.
What happens in fs/proc/meminfo.c is this calculation:
allowed = ((totalram_pages - hugetlb_total_pages()) * sysctl_overcommit_ratio / 100) + total_swap_pages;
The problem is that hugetlb_total_pages() is larger than totalram_pages resulting in a negative number. Since allowed is an unsigned long the negative shows up as a big number.
A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.
A symptom of this problem is that /proc/meminfo prints a very large CommitLimit number.
CommitLimit: 737869762947802600 kB
To reproduce the problem reserve over half of memory as hugepages. For example "default_hugepagesz=1G hugepagesz=1G hugepages=64 Then look at /proc/meminfo .
uv1-sys:~ # cat /proc/meminfo MemTotal: 32395508 kB MemFree: 32029276 kB Buffers: 8656 kB Cached: 89548 kB SwapCached: 0 kB Active: 55336 kB Inactive: 73916 kB Active(anon): 31220 kB Inactive(anon): 36 kB Active(file): 24116 kB Inactive(file): 73880 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 1692 kB Writeback: 0 kB AnonPages: 31132 kB Mapped: 15668 kB Shmem: 152 kB Slab: 70256 kB SReclaimable: 17148 kB SUnreclaim: 53108 kB KernelStack: 6536 kB PageTables: 3704 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 737869762947802600 kB Committed_AS: 394044 kB VmallocTotal: 34359738367 kB VmallocUsed: 713960 kB VmallocChunk: 34325764204 kB HardwareCorrupted: 0 kB HugePages_Total: 32 HugePages_Free: 32 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 1048576 kB DirectMap4k: 16384 kB DirectMap2M: 2064384 kB DirectMap1G: 65011712 kB
-- Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc rja@sgi.com
| |