Re: oom: Bogus "sysrq: OOM request ignored because killer is disabled" message

[Michal Hocko <mhocko@kernel.org>]

On Mon 03-04-17 12:20:29, Michal Hocko wrote:
> On Mon 03-04-17 13:10:41, Vladimir Davydov wrote:
> > On Mon, Apr 03, 2017 at 11:11:53AM +0200, Michal Hocko wrote:
> > > [Fixup Vladimir email address]
> > > 
> > > On Mon 03-04-17 10:38:00, Michal Hocko wrote:
[...]
> > > > The real reason is that there are no eligible tasks for the OOM killer
> > > > to select but since 7c5f64f84483bd13 ("mm: oom: deduplicate victim
> > > > selection code for memcg and global oom") the semantic of out_of_memory
> > > > has changed without updating moom_callback.
> > > > 
> > > > This patch updates moom_callback to tell that no task was eligible
> > > > which is the case for both oom killer disabled and no eligible tasks.
> > > > In order to help distinguish first case from the second add printk to
> > > > both oom_killer_{enable,disable}. This information is useful on its own
> > > > because it might help debugging potential memory allocation failures.
> > 
> > I think this makes sense although personally I find the "No task
> > eligible" message in case OOM killer is disabled manually a bit
> > confusing: the thing is in order to find out why an OOM request
> > failed you'll have to scan the full log, which might be unavailable.
> > May be, we'd better just make out_of_memory() return true in case
> > is_sysrq_oom() is true and no task was found, as it used to be.
> 
> Well, the thing is that the oom killer is disabled only during the PM
> suspend and I do not expect we would grow new users. And it is quite
> unlikely to invoke sysrq during that time. The OOM killer is disabled is
> unlikely to be too far in the past in that case. It is also a matter of
> fact that no tasks are eligible during that time period so the message
> is not misleading. I have considered is_sysrq_oom approach but I would
> rather not add yet another exception for that path, we have quite some
> of them already. Especially when the only point of that exception would
> be to control a log message.

Does this reasoning make sense to you? Can I post the patch to Andrew or
you sill see strong reasons to tweak out_of_memory?
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>