[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1401121404530.20999@chino.kir.corp.google.com>
Date: Sun, 12 Jan 2014 14:10:49 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Johannes Weiner <hannes@...xchg.org>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.cz>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
cgroups@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [patch 1/2] mm, memcg: avoid oom notification when current needs
access to memory reserves
On Fri, 10 Jan 2014, Johannes Weiner wrote:
> > > > It was acked-by Michal.
>
> Michal acked it before we had most of the discussions and now he is
> proposing an alternate version of yours, a patch that you are even
> discussing with him concurrently in another thread. To claim he is
> still backing your patch because of that initial ack is disingenuous.
>
His patch depends on mine, Johannes.
> > Johannes is arguing for the same semantics that VMPRESSURE_CRITICAL and/or
> > memory thresholds provides, which disagrees from the list of solutions
> > that Documentation/cgroups/memory.txt gives for userspace oom handler
> > wakeups and is required for any sane implementation.
>
> No, he's not and I'm sick of you repeating refuted garbage like this.
>
> You have convinced neither me nor Michal that your problem is entirely
> real and when confronted with doubt you just repeat the same points
> over and over.
>
The conditional to check if current needs access to memory reserves to
make forward progress and avoid oom killing anything else is done after
the memcg notification. It's real per section 6.8.4 of the C99 standard
which defines how a conditional works. We do not want a userspace
notification in such a case because userspace testing of whether the
condition is actionable would be unreliable. This is not dead code, it
does get executed.
> The one aspect of your change that we DO agree is valid is now fixed
> by Michal in a separate attempt because you could not be bothered to
> incorporate feedback into your patch.
>
I suggested his patch, Johannes, but his patch depends on mine. I'm
hoping he can rebase his patch and it's done and merged into -mm before
the merge window for 3.14 as I've stated.
--
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