linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To: Michal Hocko <mhocko@suse.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: Mon, 12 Jun 2017 14:37:18 -0400	[thread overview]
Message-ID: <20170612183717.qgcusdfvdfcj7zr7@oracle.com> (raw)
In-Reply-To: <20170612174911.GA23493@dhcp22.suse.cz>

* Michal Hocko <mhocko@suse.com> [170612 13:49]:
> On Mon 12-06-17 13:28:30, Liam R. Howlett wrote:
> > * Michal Hocko <mhocko@suse.com> [170606 02:01]:
> [..]
> > > 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?
> > 
> > I think telling the user that something failed is very useful.  This
> > obviously does not cover off all failure cases as you have pointed out,
> > but it is certainly better than silently continuing as is the case
> > today.
> > 
> > Are you suggesting that the error message be provided if the failure
> > happens after boot as well?
> 
> No, I am just suggesting that the warning as proposed is not useful and
> it is worth the additional (aleit little) code. It doesn't cover many
> other miscofigurations which might be even more serious because there
> would be still _some_ memory left while the system would crawl to death.

There is already some memory left as long as the huge page size doesn't
work out to be exactly the amount of free pages.  This is why it's so
annoying as the OOM kicks in much later in the boot process and leaves
it up to the user to debug a kernel dump with zero error or warning
messages about what happened before things went bad.  Worse yet, I've
seen several pages of OOMs scroll by as each processor takes turns
telling the user it is out of memory.  If there's no message stating any
configuration issue, then many admins would probably think something is
seriously broken and it's not just a simple typo of K vs M.

Even though this doesn't catch all errors, I think it's a worth while
change since this is currently a silent failure which results in a
system crash.

> 
> My objections are not hard enough to give a right NAK I just think this
> is a pointless code which won't help the current situation much.

I'm opened to other suggestions on how to make this better, but
providing the user with more information seems like a good start.  I
think it's reasonable to think many end users would not know what to do
with a kernel oops when no errors or warnings have occurred.

Thanks,
Liam

--
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-12 18:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03  0:54 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
2017-06-12 17:28         ` Liam R. Howlett
2017-06-12 17:49           ` Michal Hocko
2017-06-12 18:37             ` Liam R. Howlett [this message]
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=20170612183717.qgcusdfvdfcj7zr7@oracle.com \
    --to=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=mhocko@suse.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox