Thread (17 messages) 17 messages, 4 authors, 2017-08-01

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

From: Liam R. Howlett <hidden>
Date: 2017-08-01 01:26:29

* Michal Hocko [off-list ref] [170731 10:49]:
On Mon 31-07-17 07:37:35, Matthew Wilcox wrote:
quoted
On Mon, Jul 31, 2017 at 04:08:10PM +0200, Michal Hocko wrote:
quoted
On Mon 31-07-17 09:56:48, Liam R. Howlett wrote:
[...]
quoted
quoted
quoted
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help