lkml.org 
[lkml]   [2011]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm: fix negative commitlimit when gigantic hugepages are allocated
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.



\
 
 \ /
  Last update: 2011-06-13 23:35    [W:0.051 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site