linux-kernel - oom: Be less verbose

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-next>] [day] [month] [year] [list]

Message-Id: <1401976841-3899-1-git-send-email-richard@nod.at>
Date:	Thu,  5 Jun 2014 16:00:40 +0200
From:	Richard Weinberger <richard@....at>
To:	hannes@...xchg.org
Cc:	mhocko@...e.cz, 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: oom: Be less verbose

Processes within Linux containers very often hit their memory limits.
This has the side effect that the kernel log gets spammed all day with
useless OOM messages.
If a userspace program listens to the memory cgroup event fd to
get notified upon OOM we can avoid this spamming and be less verbose.

With this patch applied the OOM killer will only print much details
if nobody listens to the affected memory cgroup event fd.
I can also think of a new sysctl like "vm.oom_verbose=1" to guarantee the old
behavior even if we have listeners.

What do you think?

Thanks,
//richard

[RFC][PATCH] oom: Be less verbose if the oom_control event fd has listeners
--
 include/linux/memcontrol.h |    6 ++++++
 mm/memcontrol.c            |   20 ++++++++++++++++++++
 mm/oom_kill.c              |    2 +-
 3 files changed, 27 insertions(+), 1 deletion(-)

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