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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
