All of lore.kernel.org
 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: Tue, 13 Jun 2017 11:25:02 -0400	[thread overview]
Message-ID: <20170613152501.w27r2q2agy4sue5x@oracle.com> (raw)
In-Reply-To: <20170613054204.GB5363@dhcp22.suse.cz>

* Michal Hocko <mhocko@suse.com> [170613 01:42]:
> On Mon 12-06-17 21:35:17, Liam R. Howlett wrote:
> [...]
> > Understood.  Again, I appreciate all the time you have taken on my
> > patch and explaining your points.  I will look at this again as you
> > have suggested.
> 
> One way to go forward might be to check the size of the per node pool
> and warn if it grows over a certain threshold of the available memory
> on that node. I do not have a good idea what would be that threshold,
> though. It will certainly depend on workloads. I can also imagine that
> somebody might want to dedicate the full numa node for hugetlb pages
> and still be OK so take this suggestion with some reserve. It is hard
> to protect against misconfigurations in general but maybe you will find
> some way here.

I thought about an upper threshold of memory and discussed it
internally, but came to the same conclusion; it may be desired and
there's no safe bet beyond warning if the user requests over 100% of the
memory.  In the case of requesting over 100% of the memory, we could
warn the user and specify what was allocated.  Would it be reasonable to
warn on both boot and through sysfs of such requests?  I'm concerned
that this is yet another too-targeted approach.

The OOM issue would still arise much later in boot for the init
situation.  I have an OOM patch I'd like to send out for another hugetlb
corner case which may improve this situation.  I was going to send it
out separately as I thought of it as unrelated to this scenario and I
believe it should be a config option.  The OOM patch has its own issues
and would only be an RFC at this point.

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-13 15:25 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
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 [this message]
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=20170613152501.w27r2q2agy4sue5x@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 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.