On Wed 25-10-17 21:15:24, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Wed 25-10-17 19:48:09, Tetsuo Handa wrote: > > > Michal Hocko wrote: > > [...] > > > > The OOM killer is the last hand break. At the time you hit the OOM > > > > condition your system is usually hard to use anyway. And that is why I > > > > do care to make this path deadlock free. I have mentioned multiple times > > > > that I find real life triggers much more important than artificial DoS > > > > like workloads which make your system unsuable long before you hit OOM > > > > killer. > > > > > > Unable to invoke the OOM killer (i.e. OOM lockup) is worse than hand break injury. > > > > > > If you do care to make this path deadlock free, you had better stop depending on > > > mutex_trylock(&oom_lock). Not only printk() from oom_kill_process() can trigger > > > deadlock due to console_sem versus oom_lock dependency but also > > > > And this means that we have to fix printk. Completely silent oom path is > > out of question IMHO > > We cannot fix printk() without giving enough CPU resource to printk(). This is a separate discussion but having a basically unbound time spent in printk is simply a no-go. > I don't think "Completely silent oom path" can happen, for warn_alloc() is called > again when it is retried. But anyway, let's remove warn_alloc(). I mean something else. We simply cannot do the oom killing without telling userspace about that. And printk is the only API we can use for that. -- Michal Hocko SUSE Labs -- 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>
