On Wed, 6 Nov 2013, Sameer Nanda wrote: > David -- I think we can make the duration that the tasklist_lock is > held smaller by consolidating the process selection logic that is > currently split across select_bad_process and oom_kill_process into > one place in select_bad_process. The tasklist_lock would then need to > be held only when the thread lists are being traversed. Would you be > ok with that? I can re-spin the patch if that sounds like a workable > option. > No, this caused hundreds of machines to hit soft lockups for Google because there's no synchronization that prevents dozens of cpus to take tasklist_lock in the oom killer during parallel memcg oom conditions and never allow the write_lock_irq() on fork() or exit() to make progress. We absolutely must hold tasklist_lock for as little time as possible in the oom killer. That said, I've never actually seen your reported bug manifest in our production environment so let's see if Oleg has any ideas. -- 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>