On Fri 28-07-17 14:33:47, Kirill A. Shutemov wrote: > 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. System can recover from the OOM killer in most cases and there is no real reason to break contracts which administrator established. On the other hand you cannot assume correct operation of the SW which depends on hugetlb pages in general. Such a SW might get unexpected crashes/data corruptions and what not. > I think we can allow hugetlb reclaim just to keep system alive, taint > kernel and indicate that "reboot needed". Let me repeat, this is an admin only configuration and we cannot pretend to fix those decisions. If there is a configuration issue it should be fixed and the OOM killer along with the oom report explaining the situation is the best way forward IMO. -- Michal Hocko SUSE Labs -- 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>
