On Fri, Apr 17, 2020 at 9:04 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2020/04/17 20:57, Yafang Shao wrote: > >>>>> I justed worried that the user may complain it if too many > >>>>> oom_kill_process callbacks are suppressed. > >>>> > >>>> This can be a real concern indeed. > >> > >> I'm proposing automated ratelimiting of dump_tasks() at > >> http://lkml.kernel.org/r/1563360901-8277-1-git-send-email-penguin-kernel@xxxxxxxxxxxxxxxxxxx . > >> I believe that automated ratelimiting of dump_tasks() remains necessary > >> even after printk() became asynchronous. > >> > > > > Thanks for your information. > > I haven't read your proposal carefully, but take a first glance I > > think it would be a useful improvement. > > Thank you. That patch alone avoids just RCU stall. But > https://lkml.kernel.org/r/7de2310d-afbd-e616-e83a-d75103b986c6@xxxxxxxxxxxxxxxxxxx and > https://lkml.kernel.org/r/57be50b2-a97a-e559-e4bd-10d923895f83@xxxxxxxxxxxxxxxxxxx > referenced from that thread allows defer printing of OOM victim candidates. And > > >>> Yes, printk being too sync is the real issue. If the printk an be > >>> async, then we don't need to worry about it at all. > >> > >> I strongly disagree. dump_tasks() will needlessly fill printk() log buffer > >> (and potentially loose other kernel messages due to buffer full / disk full). > >> > > > > Yup, printk() log buffer will be a issue if the console is too slow. > > After the printk() is implemented as async, I thinks it is worth to do > > some optimization. > > my suggestion is to offload printing of OOM victim candidates to a workqueue context. > Then, even after printk() became asynchronous, that workqueue waits for completion of > printing to consoles for each OOM victim candidate. This way, only dump_tasks() where > dumping of past OOM-killer invocations has not completed will suppress dump_tasks() > from later OOM-killer invocations in a way duplicated OOM victims won't be reported > for many times (and also saves printk() log buffer / disk space). > Sounds like a good idea. > I need real world reports (like your report)... I'd appreciate it if my report could help you. Feel free to let me know if you need more infomation. Thanks Yafang
