On Tue 11-04-17 20:43:05, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Mon 10-04-17 15:03:08, Andrew Morton wrote: > > > On Mon, 10 Apr 2017 20:58:13 +0900 Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > Patch "mm: page_alloc: __GFP_NOWARN shouldn't suppress stall warnings" > > > > changed to drop __GFP_NOWARN when calling warn_alloc() for stall warning. > > > > Although I suggested for two times to drop __GFP_NOWARN when warn_alloc() > > > > for stall warning was proposed, Michal Hocko does not want to print stall > > > > warnings when __GFP_NOWARN is given [1][2]. > > > > > > > > "I am not going to allow defining a weird __GFP_NOWARN semantic which > > > > allows warnings but only sometimes. At least not without having a proper > > > > way to silence both failures _and_ stalls or just stalls. I do not > > > > really thing this is worth the additional gfp flag." > > > > > > 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. > > > > This is what the patch from Johannes already does and you have it in the > > mmotm tree. > > > > > Unless it's known to cause a problem for the stall warning to come out > > > for __GFP_NOWARN attempts? If so then perhaps a > > > __GFP_NOWARN_ABOUT_STALLS is needed? > > > > And this is one of the reason why I didn't like it. But whatever it > > doesn't make much sense to spend too much time discussing this again. > > This patch doesn't really fix anything important IMHO and it just > > generates more churn. > > This patch does not fix anything important for Michal Hocko, but > this patch does find something important (e.g. GFP_NOFS | __GFP_NOWARN > allocations) I fail to see where it does that. > for administrators and troubleshooting staffs at support > centers. As a troubleshooting staff, giving administrators some clue to > start troubleshooting is critically important. > > Speak from my experience, hardcoded 10 seconds is really useless. > Some cluster system has only 10 seconds timeout for failover. Failing > to report allocations stalls longer than a few seconds can make this > warn_alloc() pointless. On the other hand, some administrators do not > want to receive this warn_alloc(). If we had tunable interface like > /proc/sys/kernel/memalloc_task_warning_secs , we can handle both cases > (assuming that stalling allocations can reach this warn_alloc() within > a few seconds; if this assumption does not hold, only allocation watchdog > can handle it). This repeating of "hypotetical" demand of tunable is getting boring. I would really appreciate to see at least _one_ such report from the field. If you do not have any please stop wasting others people time by unfounded claims. -- 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>
