On Wed, Nov 05, 2014 at 11:54:28AM -0500, Tejun Heo wrote: > > Still not following. How do you want to detect an on-going OOM without > > any interface around out_of_memory? > > I thought you were using oom_killer_allowed_start() outside OOM path. > Ugh.... why is everything weirdly structured? oom_killer_disabled > implies that oom killer may fail, right? Why is > __alloc_pages_slowpath() checking it directly? If whether oom killing > failed or not is relevant to its users, make out_of_memory() return an > error code. There's no reason for the exclusion detail to leak out of > the oom killer proper. The only interface should be disable/enable > and whether oom killing failed or not. And what's implemented is wrong. What happens if oom killing is already in progress and then a task blocks trying to write-lock the rwsem and then that task is selected as the OOM victim? disable() call must be able to fail. -- tejun -- 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>