On Wed 19-04-17 15:22:16, Stanislaw Gruszka wrote: > On Wed, Apr 19, 2017 at 01:13:43PM +0200, Michal Hocko wrote: > > On Tue 18-04-17 14:47:32, David Rientjes wrote: > > [...] > > > I think the debug_guardpage_minorder() check makes sense for failed > > > allocations because we are essentially removing memory from the system for > > > debug, failed allocations as a result of low on memory or fragmentation > > > aren't concerning if we are removing memory from the system. > > > > I really fail to see how this is any different from booting with > > mem=$SIZE to reduce the amount of available memory. > > mem= shrink upper memory limit, debug_guardpage_minorder= fragments > available physical memory (deliberately to catch unintended access). Yeah but both make allocation failures (especially higher order ones) more likely. So I really fail to see the point inhibit allocation failure warning for one and not for the other. This whole special casing of debug_guardpage_minorder is just too strange to me. We do have a rate limit to not flood the log. -- 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>
