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: > > 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 <mhocko@xxxxxxxx> 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
