On Mon, 10 Apr 2017, Andrew Morton wrote: > I interpret __GFP_NOWARN to mean "don't warn about this allocation > attempt failing", not "don't warn about anything at all". It's a very > minor issue but yes, methinks that stall warning should still come out. > Agreed, and we have found this to be helpful in automated memory stress tests. I agree that masking off __GFP_NOWARN and then reporting the gfp_mask to the user is only harmful. If the allocation stalls vs allocation failure warnings are separated such as you have done, it is easily preventable. I have a couple of suggestions for Tetsuo about this patch, though: - We now have show_mem_rs, stall_rs, and nopage_rs. Ugh. I think it's better to get rid of show_mem_rs and let warn_alloc_common() not enforce any ratelimiting at all and leave it to the callers. - warn_alloc() is probably better off renamed to warn_alloc_failed() since it enforces __GFP_NOWARN and uses an allocation failure ratelimit regardless of what the passed text is. It may also be slightly off-topic, but I think it would be useful to print current's pid. I find printing its parent's pid and comm helpful when using shared libraries, but you may not agree. Otherwise, I think this is a good direction. -- 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>
