On Tue, 8 Jun 2010, Andrew Morton wrote: > > The oom killer tasklist dump, enabled with the oom_dump_tasks sysctl, is > > very helpful information in diagnosing why a user's task has been killed. > > It emits useful information such as each eligible thread's memory usage > > that can determine why the system is oom, so it should be enabled by > > default. > > Unclear. On a large system the poor thing will now spend half an hour > squirting junk out the diagnostic port. Probably interspersed with the > occasional whine from the softlockup detector. And for many > applications, spending a long time stuck in the kernel printing > diagnostics is equivalent to an outage. > > I guess people can turn it off again if this happens, but they'll get > justifiably grumpy at us. I wonder if this change is too > developer-friendly and insufficiently operator-friendly. > This is one of the main reasons why I wanted to unify both oom_kill_allocating_task and oom_dump_tasks into a single sysctl: oom_kill_quick, but that was nacked. Both of the former sysctls have the same audience: those that want to avoid lengthy tasklist scans, namely companies like SGI, by enabling the first and disabling the second. If we were to extend the oom killer in the future and need to add special handling for these customers, it would have been easy with the unified sysctl, but I'm not going to wage that war again. I think this is more helpful than harmful, however, solely because it gives users a better indication of what caused their system to be oom in the first place and can be disabled at runtime. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>