Michal Hocko wrote: > On Fri 15-04-16 00:03:31, Tetsuo Handa wrote: > > Michal Hocko wrote: > [...] > > > I would rather be explicit that we _do not care_ > > > about these configurations. It is just PITA maintain and it doesn't make > > > any sense. So rather than trying to document all the weird thing that > > > might happen I would welcome a warning "mm shared with OOM_SCORE_ADJ_MIN > > > task. Something is broken in your configuration!" > > > > Would you please stop rejecting configurations which do not match your values? > > Can you point out a single real life example where the above > configuration would make a sense? This is not about _my_ values. This is > about general _sanity_. If two/more entities share the mm and they disagree > about their OOM priorities then something is clearly broken. Don't you think? > How can the OOM killer do anything sensible here? The API we have > created is broken because it allows broken configurations too easily. It > is too late to fix it though so we can only rely on admins to use it > sensibly. I explained it at http://lkml.kernel.org/r/201603152015.JAE86937.VFOLtQFOFJOSHM@xxxxxxxxxxxxxxxxxxx . I don't do such usage does not mean nobody does such usage. > > So please try to step back and think about whether it actually make > sense to make the oom even more complex/confusing for something that > gives little (if any) sense. Syscalls respond with "your usage is invalid" (by returning -EINVAL) than "ignore such usage and crash" (by triggering kernel panic). Why the OOM killer cannot respond with "I need to kill a different victim" than "ignore and silently hang up" ? Doing so with bounded wait is trivial and also helps "Whenever we select a victim and call mark_oom_victim we hope it will eventually get out of its kernel code path" problem. -- 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>