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

[Vladimir Davydov <vdavydov@tarantool.org>]

On Tue, Apr 04, 2017 at 03:23:50PM +0200, Michal Hocko wrote:
> 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?

I think your arguments are fair enough. I don't have any objections.

Thanks.

--
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>