On Sat 22-04-17 10:10:34, Stanislaw Gruszka wrote: [...] > > 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. > > I added this check to skip warning if buddy allocator fail, what I > considered likely scenario taking the conditions. The check remove > warning completely, rate limit only limit the speed warnings shows in > logs. Yes and this is what I argue against. The feature limits the amount of _usable_ memory and as such it changes the behavior of the allocator which can lead to all sorts of problems (including high memory pressure, stalls, OOM etc.). The warning is there to help debug all those problems and removing it just changes that behavior in an unexpected way. This is just wrong thing to do IMHO. Even worse so when it motivates to make other code in the allocator more complicated. If there is really a problem logs flooded by the allocation failures while using the guard page we should address it by a more strict ratelimiting. -- 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>
