On Tue 2019-09-03 23:20:48, Tetsuo Handa wrote: > On 2019/09/02 15:06, Michal Hocko wrote: > > On Sat 31-08-19 10:03:18, Tetsuo Handa wrote: > >> On 2019/08/30 19:35, Michal Hocko wrote: > >>> On Fri 30-08-19 19:04:53, Tetsuo Handa wrote: > >>>> If /proc/sys/vm/oom_dump_tasks != 0, dump_header() can become very slow > >>>> because dump_tasks() synchronously reports all OOM victim candidates, and > >>>> as a result ratelimit test for dump_header() cannot work as expected. > >>>> > >>>> This patch defers dump_tasks() till oom_mutex is released. As a result of > >>>> this patch, the latency between out_of_memory() is called and SIGKILL is > >>>> sent (and the OOM reaper starts reclaiming memory) will be significantly > >>>> reduced. > >>> > >>> This is adding a lot of code for something that might be simply worked > >>> around by disabling dump_tasks. Unless there is a real world workload > >>> that suffers from the latency and depends on the eligible task list then > >>> I do not think this is mergeable. > >>> > >> > >> People had to use /proc/sys/vm/oom_dump_tasks == 0 (and give up obtaining some > >> clue) because they worried stalls caused by /proc/sys/vm/oom_dump_tasks != 0 > >> while they have to use /proc/sys/vm/panic_on_oom == 0 because they don't want the > >> down time caused by rebooting. > > > > The main qustion is whether disabling that information is actually > > causing any real problems. > > I can't interpret your question. > If there is no real problem with forcing /proc/sys/vm/oom_dump_tasks == 0, > you had better remove dump_tasks(). > > > > >> This patch avoids stalls (and gives them some clue). > >> This patch also helps mitigating __ratelimit(&oom_rs) == "always true" problem. > >> A straightforward improvement. > > > > This is a wrong approach to mitigate that problem. Ratelimiting doesn't > > really work for any operation that takes a longer time. Solving that > > problem sounds usef in a generic way. > > Even if printk() is able to become asynchronous, a problem that "a lot of > printk() messages might be pending inside the printk buffer when we have to > write emergency messages to consoles due to entering critical situation" will remain. > This patch prevents dump_tasks() messages (which can become e.g. 32000 lines) from > pending in the printk buffer. Sergey and Petr, any comments to add? I am not sure that I understand. If OOM messages are critical then they should get printed synchronously. It they are not critical then they can get deferred. John Ogness has a proposal[1] to introduce one more console loglevel that would split messages into two groups. Emergency messages would get printed synchronously and the rest might get deferred. But there are many prerequisites and questions about it: + lockless consoles to print emergency messages immediately + offload mechanism + user space support to sort the messages by timestamps + usage and code complexity vs. the gain Anyway, this is a generic way how to solve these problems. [1] https://lkml.kernel.org/r/20190212143003.48446-1-john.ogness@xxxxxxxxxxxxx Best Regards, Petr
