Re: [PATCH] mm: fix negative commitlimit when gigantic hugepages are allocated

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 13 Jun 2011 18:11:55 -0300
Rafael Aquini <aquini@linux.com> wrote:

> Howdy Andrew,
> 
> Sorry, for this late reply.
> 
> On Thu, Jun 09, 2011 at 04:44:08PM -0700, Andrew Morton wrote:
> > On Thu, 2 Jun 2011 23:55:57 -0300
> > Rafael Aquini <aquini@linux.com> wrote:
> > 
> > > When 1GB hugepages are allocated on a system, free(1) reports
> > > less available memory than what really is installed in the box.
> > > Also, if the total size of hugepages allocated on a system is
> > > over half of the total memory size, CommitLimit becomes
> > > a negative number.
> > > 
> > > The problem is that gigantic hugepages (order > MAX_ORDER)
> > > can only be allocated at boot with bootmem, thus its frames
> > > are not accounted to 'totalram_pages'. However,  they are
> > > accounted to hugetlb_total_pages()
> > > 
> > > What happens to turn CommitLimit into a negative number
> > > is this calculation, in fs/proc/meminfo.c:
> > > 
> > >         allowed = ((totalram_pages - hugetlb_total_pages())
> > >                 * sysctl_overcommit_ratio / 100) + total_swap_pages;
> > > 
> > > A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.
> > > 
> > > Also, every vm statistic which depends on 'totalram_pages' will render
> > > confusing values, as if system were 'missing' some part of its memory.
> > 
> > Is this bug serious enough to justify backporting the fix into -stable
> > kernels?
> 
> Despite not having testing it, I can think the following scenario as
> troublesome:
> When gigantic hugepages are allocated and sysctl_overcommit_memory == OVERCOMMIT_NEVER.
> In a such situation, __vm_enough_memory() goes through the mentioned 'allowed'
> calculation and might end up mistakenly returning -ENOMEM, thus forcing
> the system to start reclaiming pages earlier than it would be ususal, and this could
> cause detrimental impact to overall system's performance, depending on the
> workload.
> 
> Besides the aforementioned scenario, I can only think of this causing annoyances
> with memory reports from /proc/meminfo and free(1).
> 

hm, OK, thanks.  That sounds a bit thin, but the patch is really simple
so I stuck the cc:stable onto its changelog.