From: Rafael Aquini <aquini@linux.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Russ Anderson <rja@sgi.com>,
Andrea Arcangeli <aarcange@redhat.com>,
linux-mm <linux-mm@kvack.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Christoph Lameter <cl@linux.com>,
rja@americas.sgi.com
Subject: Re: [PATCH] mm: fix negative commitlimit when gigantic hugepages are allocated
Date: Mon, 13 Jun 2011 18:11:55 -0300 [thread overview]
Message-ID: <20110613211153.GA23597@optiplex.tchesoft.com> (raw)
In-Reply-To: <20110609164408.8370746e.akpm@linux-foundation.org>
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).
Thanks for your attention!
Cheers!
--
Rafael Aquini <aquini@linux.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-06-13 21:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-18 15:34 [PATCH] [BUGFIX] mm: hugepages can cause negative commitlimit Russ Anderson
2011-05-19 0:51 ` Rafael Aquini
2011-05-19 4:56 ` Russ Anderson
2011-05-19 13:37 ` Rafael Aquini
2011-05-19 22:11 ` Russ Anderson
2011-05-20 20:04 ` Andrew Morton
2011-05-20 22:30 ` Rafael Aquini
2011-05-26 21:07 ` Rafael Aquini
2011-05-27 22:22 ` Russ Anderson
2011-06-02 4:08 ` Russ Anderson
2011-06-03 2:55 ` [PATCH] mm: fix negative commitlimit when gigantic hugepages are allocated Rafael Aquini
2011-06-03 12:07 ` Russ Anderson
2011-06-09 23:44 ` Andrew Morton
2011-06-13 21:11 ` Rafael Aquini [this message]
2011-06-13 21:31 ` Andrew Morton
2011-06-03 3:08 ` [PATCH] [BUGFIX] mm: hugepages can cause negative commitlimit Rafael Aquini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110613211153.GA23597@optiplex.tchesoft.com \
--to=aquini@linux.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rja@americas.sgi.com \
--cc=rja@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox