On Fri, Jul 28, 2017 at 08:46:02AM +0200, Michal Hocko wrote:

On Thu 27-07-17 14:02:36, Liam R. Howlett wrote:

quoted

When a system runs out of memory it may be desirable to reclaim
unreserved hugepages.  This situation arises when a correctly configured
system has a memory failure and takes corrective action of rebooting and
removing the memory from the memory pool results in a system failing to
boot.  With this change, the out of memory handler is able to reclaim
any pages that are free and not reserved.

I am sorry but I have to Nack this. You are breaking the basic contract
of hugetlb user API. Administrator configures the pool to suit a
workload. It is a deliberate and privileged action. We allow to
overcommit that pool should there be a immediate need for more hugetlb
pages and we do remove those when they are freed. If we don't then this
should be fixed.
Other than that hugetlb pages are not reclaimable by design and users
do rely on that. Otherwise they could consider using THP instead.

If somebody configures the initial pool too high it is a configuration
bug. Just think about it, we do not want to reset lowmem reserves
configured by admin just because we are hitting the oom killer and yes
insanely large lowmem reserves might lead to early OOM as well.

Nacked-by: Michal Hocko [off-list ref]

Hm. I'm not sure it's fully justified. To me, reclaiming hugetlb is
something to be considered as last resort after all other measures have
been tried.

I think we can allow hugetlb reclaim just to keep system alive, taint
kernel and indicate that "reboot needed".

The situation is somewhat similar to BUG() vs. WARN().

-- 
 Kirill A. Shutemov

--
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>