On Fri 28-07-17 14:23:50, Michal Hocko wrote: > 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. And to be clear. The memory hotpug currently does the similar thing via dissolve_free_huge_pages and I believe that is wrong as well although one could argue that the memory offline is an admin action as well so reducing hugetlb pages is a reasonable thing to do. This would be for a separate discussion though. But OOM can happen for entirely different reasons and hugetlb might be configured properly while this change would simply break that setup. This is simply nogo. -- 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>
