* Michal Hocko <mhocko@xxxxxxxx> [170613 01:42]: > On Mon 12-06-17 21:35:17, Liam R. Howlett wrote: > [...] > > Understood. Again, I appreciate all the time you have taken on my > > patch and explaining your points. I will look at this again as you > > have suggested. > > One way to go forward might be to check the size of the per node pool > and warn if it grows over a certain threshold of the available memory > on that node. I do not have a good idea what would be that threshold, > though. It will certainly depend on workloads. I can also imagine that > somebody might want to dedicate the full numa node for hugetlb pages > and still be OK so take this suggestion with some reserve. It is hard > to protect against misconfigurations in general but maybe you will find > some way here. I thought about an upper threshold of memory and discussed it internally, but came to the same conclusion; it may be desired and there's no safe bet beyond warning if the user requests over 100% of the memory. In the case of requesting over 100% of the memory, we could warn the user and specify what was allocated. Would it be reasonable to warn on both boot and through sysfs of such requests? I'm concerned that this is yet another too-targeted approach. The OOM issue would still arise much later in boot for the init situation. I have an OOM patch I'd like to send out for another hugetlb corner case which may improve this situation. I was going to send it out separately as I thought of it as unrelated to this scenario and I believe it should be a config option. The OOM patch has its own issues and would only be an RFC at this point. Thanks, Liam -- 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>
