On Mon 12-12-16 23:59:55, Tetsuo Handa wrote: > Michal Hocko wrote: > > On Mon 12-12-16 21:12:06, Tetsuo Handa wrote: > > > > I would rather not mix the two. Even if both use show_mem then there is > > > > no reason to abuse the oom_lock. > > > > > > > > Maybe I've missed that but you haven't responded to the question whether > > > > the warn_lock actually resolves the problem you are seeing. > > > > > > I haven't tried warn_lock, but is warn_lock in warn_alloc() better than > > > serializing oom_lock in __alloc_pages_may_oom() ? I think we don't need to > > > waste CPU cycles before the OOM killer sends SIGKILL. > > > > Yes, I find a separate lock better because there is no real reason to > > abuse an unrelated lock. > > Using separate lock for warn_alloc() is fine for me. I can still consider > serialization of oom_lock independent with warn_alloc(). Could you try the ratelimit update as well? Maybe it will be sufficient on its own. > But > > > > Maybe more, but no need to enumerate in this thread. > > > How many of these precautions can be achieved by tuning warn_alloc() ? > > > printk() tries to solve unbounded delay problem by using (I guess) a > > > dedicated kernel thread. I don't think we can achieve these precautions > > > without a centralized state tracking which can sleep and synchronize as > > > needed. > > > > > > Quite few people are responding to discussions regarding almost > > > OOM situation. I beg for your joining to discussions. > > > > I have already stated my position. I do not think that the code this > > patch introduces is really justified for the advantages it provides over > > a simple warn_alloc approach. Additional debugging information might be > > nice but not necessary in 99% cases. If there are definciences in > > warn_alloc (which I agree there are if there are thousands of contexts > > hitting the path) then let's try to address them. > > I'm not happy with keeping kmallocwd out-of-tree. I completely fail why you are still bringing this up. I will repeat it for the last time and won't reply to any further note about kmallocwd here or anywhere else where it is not directly discussed. If you think your code is valuable document that in the patch description and post your patch. -- 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>