]> git.karo-electronics.de Git - karo-tx-linux.git/commit
mm/hugetlb: fix total hugetlbfs pages count when using memory overcommit accouting
authorWanpeng Li <liwanp@linux.vnet.ibm.com>
Wed, 20 Mar 2013 04:06:46 +0000 (15:06 +1100)
committerStephen Rothwell <sfr@canb.auug.org.au>
Thu, 21 Mar 2013 05:27:10 +0000 (16:27 +1100)
commitf387e07e00b9b52cca3cfaca22bfcc8d52ab6400
treeed25436bf32360a42e5e7426b303305b925a217a
parentbec2bc549f4671c7b7836f9ab7bd31c9998b1d91
mm/hugetlb: fix total hugetlbfs pages count when using memory overcommit accouting

hugetlb_total_pages is used for overcommit calculations but the current
implementation considers only the default hugetlb page size (which is
either the first defined hugepage size or the one specified by
default_hugepagesz kernel boot parameter).

If the system is configured for more than one hugepage size, which is
possible since a137e1cc ("hugetlbfs: per mount huge page sizes") then the
overcommit estimation done by __vm_enough_memory() (resp.  shown by
meminfo_proc_show) is not precise - there is an impression of more
available/allowed memory.  This can lead to an unexpected ENOMEM/EFAULT
resp.  SIGSEGV when memory is accounted.

Testcase:
boot: hugepagesz=1G hugepages=1
the default overcommit ratio is 50
before patch:
egrep 'CommitLimit' /proc/meminfo
CommitLimit:     55434168 kB
after patch:
egrep 'CommitLimit' /proc/meminfo
CommitLimit:     54909880 kB

Signed-off-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@vger.kernel.org> [3.0+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb.c