linux-kernel - Re: [merged] mm-memcg-handle-non-error-oom-situations-more-gracefully.patch removed from -mm tree

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: <alpine.DEB.2.02.1311291600290.22413@chino.kir.corp.google.com>
Date:	Fri, 29 Nov 2013 16:05:04 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Michal Hocko <mhocko@...e.cz>
cc:	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>, azurit@...ox.sk,
	mm-commits@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [merged] mm-memcg-handle-non-error-oom-situations-more-gracefully.patch
 removed from -mm tree

On Thu, 28 Nov 2013, Michal Hocko wrote:

> > None that I am currently aware of,
> 
> Are you saing that scenarios described in 3812c8c8f395 (mm: memcg: do not
> trap chargers with full callstack on OOM) are not real or that _you_
> haven't seen an issue like that?
> 
> The later doesn't seem to be so relevant as we had at least one user who
> has seen those in the real life.
> 

I said I'm not currently aware of any additional problems with the 
patchset, but since Johannes said the entire series wasn't meant for that 
merge window, I asked if it was still being worked on.

> > You don't think something like this is helpful after scanning a memcg will 
> > a large number of processes?
> 
> It looks as a one-shot workaround for short lived processes to me.

It has nothing to do with how long a process has been running, both racing 
processes could have been running for years.  It's obvious that even this 
patch before calling oom_kill_process() does not catch a racing process 
that has already freed its memory and is exiting but it makes the 
liklihood significantly less in testing at scale.  It's simply better to 
avoid unnecessary oom killing at anytime possible and this is not a 
hotpath.
--
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/