On Wed 17-10-18 20:17:24, Sergey Senozhatsky wrote: > On (10/17/18 12:28), Michal Hocko wrote: > > > Michal proposed ratelimiting dump_header() [2]. But I don't think that > > > that patch is appropriate because that patch does not ratelimit > > > > > > "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d, oom_score_adj=%hd\n" > > > "Out of memory and no killable processes...\n" > [..] > > > Let's make sure that next dump_header() waits for at least 60 seconds from > > > previous "Out of memory and no killable processes..." message. > > > > Could you explain why this is any better than using a well established > > ratelimit approach? > > Tetsuo, let's use a well established rate-limit approach both in > dump_hedaer() and out_of_memory(). I actually was under impression > that Michal added rate-limiting to both of these functions. I have http://lkml.kernel.org/r/20181010151135.25766-1-mhocko@xxxxxxxxxx Then the discussion took the usual direction of back and forth resulting in "you do not ratelimit the allocation oom context" and "please do that as an incremental patch" route and here we are. I do not have time and energy to argue in an endless loop. > The appropriate rate-limit value looks like something that printk() > should know and be able to tell to the rest of the kernel. I don't > think that middle ground will ever be found elsewhere. Yes, that makes sense. -- Michal Hocko SUSE Labs
