[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5390930A.8050504@nod.at>
Date: Thu, 05 Jun 2014 17:55:54 +0200
From: Richard Weinberger <richard@....at>
To: Michal Hocko <mhocko@...e.cz>
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
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 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.
Thanks,
//richard
--
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/
Powered by blists - more mailing lists