[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131211095549.GA18741@dhcp22.suse.cz>
Date: Wed, 11 Dec 2013 10:55:49 +0100
From: Michal Hocko <mhocko@...e.cz>
To: David Rientjes <rientjes@...gle.com>
Cc: Johannes Weiner <hannes@...xchg.org>,
Andrew Morton <akpm@...ux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
cgroups@...r.kernel.org
Subject: Re: [patch 1/2] mm, memcg: avoid oom notification when current needs
access to memory reserves
On Tue 10-12-13 17:03:45, David Rientjes wrote:
> On Tue, 10 Dec 2013, Michal Hocko wrote:
>
> > > What exactly would you like to see?
> >
> > How often do you see PF_EXITING tasks which haven't been killed causing
> > a pointless notification? Because fatal_signal_pending and TIF_MEMDIE
> > cases are already handled because we bypass charges in those cases (except
> > for user OOM killer killed tasks which don't get TIF_MEMDIE and that
> > should be fixed).
> >
>
> Triggering a pointless notification with PF_EXITING is rare, yet one
> pointless notification can be avoided with the patch.
Sigh. Yes it will avoid one particular and rare race. There will still
be notifications without oom kills.
Anyway.
Does the reclaim make any sense for PF_EXITING tasks? Shouldn't we
simply bypass charges of these tasks automatically. Those tasks will
free some memory anyway so why to trigger reclaim and potentially OOM
in the first place? Do we need to go via TIF_MEMDIE loop in the first
place?
> Additionally, it also avoids a pointless notification for a racing
> SIGKILL.
--
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/
Powered by blists - more mailing lists