linux-kernel - Re: [RFC][PATCH] oom: Be less verbose if the oom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140605161807.GD15939@dhcp22.suse.cz>
Date:	Thu, 5 Jun 2014 18:18:07 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Richard Weinberger <richard@....at>
Cc:	hannes@...xchg.org, bsingharora@...il.com,
	kamezawa.hiroyu@...fujitsu.com, akpm@...ux-foundation.org,
	vdavydov@...allels.com, tj@...nel.org, handai.szj@...bao.com,
	rientjes@...gle.com, oleg@...hat.com, rusty@...tcorp.com.au,
	kirill.shutemov@...ux.intel.com, linux-kernel@...r.kernel.org,
	cgroups@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC][PATCH] oom: Be less verbose if the oom_control event fd
 has listeners

On Thu 05-06-14 17:55:54, Richard Weinberger wrote:
> Am 05.06.2014 17:00, schrieb Michal Hocko:
> > On Thu 05-06-14 16:00:41, Richard Weinberger wrote:
> >> Don't spam the kernel logs if the oom_control event fd has listeners.
> >> In this case there is no need to print that much lines as user space
> >> will anyway notice that the memory cgroup has reached its limit.
> > 
> > But how do you debug why it is reaching the limit and why a particular
> > process has been killed?
> 
> In my case it's always because customer's Java application gone nuts.
> So I don't really have to debug a lot. ;-)
> But I can understand your point.

If you know that handling memcg-OOM condition is easy then maybe you can
not only listen for the OOM notifications but also handle OOM conditions
and kill the offender. This would mean that kernel doesn't try to kill
anything and so wouldn't dump anything to the log.
 
> > If we are printing too much then OK, let's remove those parts which are
> > not that useful but hiding information which tells us more about the oom
> > decision doesn't sound right to me.
> 
> What about adding a sysctl like "vm.oom_verbose"?
> By default it would be 1.
> If set to 0 the full OOM information is only printed out if nobody listens
> to the event fd.

If we have a knob then I guess it should be global and shared by memcg
as well. I can imagine that somebody might be interested only in the
tasks dump, while somebody would like to see LRU states and other memory
counters. So it would be ideally a bitmask of things to output. I do not
think that a memcg specific solution is good, though.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/