All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
	mike.kravetz@Oracle.com, n-horiguchi@ah.jp.nec.com,
	aneesh.kumar@linux.vnet.ibm.com, gerald.schaefer@de.ibm.com,
	zhongjiang@huawei.com, aarcange@redhat.com,
	kirill.shutemov@linux.intel.com
Subject: Re: [PATCH] mm/hugetlb: Warn the user when issues arise on boot due to hugepages
Date: Tue, 6 Jun 2017 08:01:48 +0200	[thread overview]
Message-ID: <20170606060147.GB1189@dhcp22.suse.cz> (raw)
In-Reply-To: <20170606054917.GA1189@dhcp22.suse.cz>

On Tue 06-06-17 07:49:17, Michal Hocko wrote:
> On Mon 05-06-17 11:15:41, Liam R. Howlett wrote:
> > * Michal Hocko <mhocko@suse.com> [170605 00:57]:
> > > On Fri 02-06-17 20:54:13, Liam R. Howlett wrote:
> > > > When the user specifies too many hugepages or an invalid
> > > > default_hugepagesz the communication to the user is implicit in the
> > > > allocation message.  This patch adds a warning when the desired page
> > > > count is not allocated and prints an error when the default_hugepagesz
> > > > is invalid on boot.
> > > 
> > > We do not warn when doing echo $NUM > nr_hugepages, so why should we
> > > behave any different during the boot?
> > 
> > During boot hugepages will allocate until there is a fraction of the
> > hugepage size left.  That is, we allocate until either the request is
> > satisfied or memory for the pages is exhausted.  When memory for the
> > pages is exhausted, it will most likely lead to the system failing with
> > the OOM manager not finding enough (or anything) to kill (unless you're
> > using really big hugepages in the order of 100s of MB or in the GBs).
> > The user will most likely see the OOM messages much later in the boot
> > sequence than the implicitly stated message.  Worse yet, you may even
> > get an OOM for each processor which causes many pages of OOMs on modern
> > systems.  Although these messages will be printed earlier than the OOM
> > messages, at least giving the user errors and warnings will highlight
> > the configuration as an issue.  I'm trying to point the user in the
> > right direction by providing a more robust statement of what is failing.
> 
> Well, an oom report will tell us how much memory is eaten by hugetlb so
> you would get a clue that something is misconfigured.

And just to be more clear. I do not _object_ to the warning I just
_think_ it is not very useful actually. If somebody misconfigure so
badly that hugetlb allocations fail during the boot then it will be
very likely visible. But if somebody misconfigures slightly less to not
fail the system is very likely to not work properly and there will be no
warning that this might be the source of problems. So is it worth adding
more code with that limited usefulness?
-- 
Michal Hocko
SUSE Labs

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-06-06  6:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03  0:54 [PATCH] mm/hugetlb: Warn the user when issues arise on boot due to hugepages Liam R. Howlett
2017-06-05  4:57 ` Michal Hocko
2017-06-05 15:15   ` Liam R. Howlett
2017-06-06  5:49     ` Michal Hocko
2017-06-06  6:01       ` Michal Hocko [this message]
2017-06-12 17:28         ` Liam R. Howlett
2017-06-12 17:49           ` Michal Hocko
2017-06-12 18:37             ` Liam R. Howlett
2017-06-12 18:52               ` Michal Hocko
2017-06-13  1:35                 ` Liam R. Howlett
2017-06-13  5:42                   ` Michal Hocko
2017-06-13 15:25                     ` Liam R. Howlett
2017-06-13 16:26                       ` Mike Kravetz
2017-06-14  7:27                         ` Michal Hocko
2017-06-14 17:02                           ` Mike Kravetz
2017-06-14  7:25                       ` Michal Hocko
2017-06-16 19:07                   ` Andrew Morton
2017-06-17  0:25                     ` Mike Kravetz
2017-06-17  6:51                     ` Michal Hocko
2017-06-19 19:59                       ` Liam R. Howlett
2017-06-05 22:38 ` Andrew Morton
2017-06-06 19:03   ` Matthew Wilcox

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=20170606060147.GB1189@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=Liam.Howlett@Oracle.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@Oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=zhongjiang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.