Re: [RFC PATCH 1/1] mm/hugetlb mm/oom_kill: Add support for reclaiming hugepages on OOM events.

["Liam R. Howlett" <Liam.Howlett@Oracle.com>]

* Michal Hocko <mhocko@kernel.org> [170731 10:49]:
> On Mon 31-07-17 07:37:35, Matthew Wilcox wrote:
> > On Mon, Jul 31, 2017 at 04:08:10PM +0200, Michal Hocko wrote:
> > > On Mon 31-07-17 09:56:48, Liam R. Howlett wrote:
> [...]
> > > > My focus on hugetlb is that it can stop the automatic recovery of the
> > > > system.
> > > 
> > > How?
> > 
> > Let me try to explain the situation as I understand it.
> > 
> > The customer has purchased a 128TB machine in order to run a database.
> > They reserve 124TB of memory for use by the database cache.  Everything
> > works great.  Then a 4TB memory module goes bad.  The machine reboots
> > itself in order to return to operation, now having only 124TB of memory
> > and having 124TB of memory reserved.  It OOMs during boot.  The current
> > output from our OOM machinery doesn't point the sysadmin at the kernel
> > command line parameter as now being the problem.  So they file a priority
> > 1 problem ticket ...
> 
> Well, I would argue that the oom report is quite clear that the hugetlb
> memory has consumed the large part if not whole usable memory and that
> should give a clue...

Can you please show me where it's clear?  Are you referring to these
messages?

Node 0 hugepages_total=15999 hugepages_free=15999 hugepages_surp=0
hugepages_size=8192kB
Node 1 hugepages_total=16157 hugepages_free=16157 hugepages_surp=0
hugepages_size=8192kB

I'm not trying to be obtuse, I'm just not sure what message in which you
are referring.

> 
> Nevertheless, I can see some merit here, but I am arguing that there
> is simply no good way to handle this without admin involvement
> unless we want to risk other and much more subtle breakage where the
> application really expects it can consume the preallocated hugetlb pool
> completely. And I would even argue that the later is more probable than
> unintended memory failure reboot cycle.  If somebody can tune hugetlb
> pool dynamically I would recommend doing so from an init script.

I agree that an admin involvement is necessary for a full recovery but
I'm trying to make the best of a bad situation.

Why can't it consume the preallocated hugetlb pool completely? I'm just
trying to make the pool a little smaller.  I thought that when the
application fails to allocate a hugetlb it would receive a failure and
need to cope with the allocation failure?

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>