On Tue 24-10-17 20:24:46, Tetsuo Handa wrote: > Michal Hocko wrote: [...] > > > So, I think that worrying about high priority threads preventing the low > > > priority thread with oom_lock held is too much. Preventing high priority > > > threads waiting for oom_lock from disturbing the low priority thread with > > > oom_lock held by wasting CPU resource will be sufficient. > > > > In other words this is just to paper over an overloaded allocation path > > close to OOM. Your changelog is really misleading in that direction > > IMHO. I have to think some more about using the full lock rather than > > the trylock, because taking the try lock is somehow easier. > > Somehow easier to what? Please don't omit. To back off on the oom races. > I consider that the OOM killer is a safety mechanism in case a system got > overloaded. Therefore, I really hate your comments like "Your system is already > DOSed". It is stupid thing that safety mechanism drives the overloaded system > worse and defunctional when it should rescue. 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. > Current code is somehow easier to OOM lockup due to printk() versus oom_lock > dependency, and I'm proposing a patch for mitigating printk() versus oom_lock > dependency using oom_printk_lock because I can hardly examine OOM related > problems since linux-4.9, and your response was "Hell no!". Because you are repeatedly proposing a paper over rather than to attempt something resembling a solution. And this is highly annoying. I've already said that I am willing to sacrifice the stall warning rather than fiddle with random locks put here and there. > > > If you don't like it, the only way will be to offload to a dedicated > > > kernel thread (like the OOM reaper) so that allocating threads are > > > no longer blocked by oom_lock. That's a big change. > > > > This doesn't solve anything as all the tasks would have to somehow wait > > for the kernel thread to do its stuff. > > Which direction are you looking at? I am sorry but I would only repeat something that has been said many times already. You keep hammering this particular issue like it was the number one problem in the MM code. We have many much more important issues to deal with. While it is interesting to make kernel more robust under OOM conditions it doesn't make much sense to overcomplicate the code for unrealistic workloads. If we have problems with real life scenarios then let's fix them, by all means. -- 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>
