diff options
| author | David Rientjes <rientjes@google.com> | 2013-04-29 15:07:48 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2013-04-29 15:54:35 -0700 |
| commit | 949f7ec5760b021da3cccc1eaeb0671270e4238f (patch) | |
| tree | 8610da7dff952d64cc59e8a922aa16fb430dd66e /mm/sparse-vmemmap.c | |
| parent | 1444f92c84984dd13f3e8e121115783ae5b22c55 (diff) | |
| download | linux-949f7ec5760b021da3cccc1eaeb0671270e4238f.tar.gz linux-949f7ec5760b021da3cccc1eaeb0671270e4238f.tar.bz2 linux-949f7ec5760b021da3cccc1eaeb0671270e4238f.zip | |
mm, hugetlb: include hugepages in meminfo
Particularly in oom conditions, it's troublesome that hugetlb memory is
not displayed. All other meminfo that is emitted will not add up to
what is expected, and there is no artifact left in the kernel log to
show that a potentially significant amount of memory is actually
allocated as hugepages which are not available to be reclaimed.
Booting with hugepages=8192 on the command line, this memory is now
shown in oom conditions. For example, with echo m >
/proc/sysrq-trigger:
Node 0 hugepages_total=2048 hugepages_free=2048 hugepages_surp=0 hugepages_size=2048kB
Node 1 hugepages_total=2048 hugepages_free=2048 hugepages_surp=0 hugepages_size=2048kB
Node 2 hugepages_total=2048 hugepages_free=2048 hugepages_surp=0 hugepages_size=2048kB
Node 3 hugepages_total=2048 hugepages_free=2048 hugepages_surp=0 hugepages_size=2048kB
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/sparse-vmemmap.c')
0 files changed, 0 insertions, 0 deletions