Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932272AbdIGQSV (ORCPT ); Thu, 7 Sep 2017 12:18:21 -0400 Received: from resqmta-ch2-01v.sys.comcast.net ([69.252.207.33]:37162 "EHLO resqmta-ch2-01v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932095AbdIGQSU (ORCPT ); Thu, 7 Sep 2017 12:18:20 -0400 Date: Thu, 7 Sep 2017 11:18:18 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Roman Gushchin cc: linux-mm@kvack.org, Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , David Rientjes , Andrew Morton , Tejun Heo , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [v7 2/5] mm, oom: cgroup-aware OOM killer In-Reply-To: <20170904142108.7165-3-guro@fb.com> Message-ID: References: <20170904142108.7165-1-guro@fb.com> <20170904142108.7165-3-guro@fb.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfIdRHSQTnitOynIXFDjN2Cq36DTYBs+ZcWDppFI8qeEnus+FdDiSz7Mpz2/mBuDBVz+Vpe64as6eydHHbItkp6cL+4gmVwbzmKyj237h2CUzwuuG1sLT q1Ft/RPMi5sF4zlDLgv0BsDO3uMLgcQe7ITRlTw5U/j5pOwLlScDYrgMWnd07NzxQcSjk9vTOFnk/Rli0A5XHznqdQDO9wpGOTYYLgDnKaSRUStZosmIlFIx GTKm2Zs4J2NRfpw6hvXB7BLPXxXsUXtj+4PIuSedg/N3IGGHD/LkiXkGNv/7L4f16XUEdwKVOu674wyNg0+pY+QeprNWrJbmiBAAcY+1J8UjM2MBsEUQ01Fw WSBHMgnxMp4D16cpMAwI7i0aAVTIZ5YI/TRkKEfNmvSm2eSZ07Q1aFJuxdYiJJMmeTjrfmEj9uCEgq6uoFm8xO3XaSVSN5enVpI+Vam95WepmbdGH9o08F/q Iz3q6uie9tjHca0NYxVgg7hEerR4n5ChzNCSzgDbLIwq1qfSqyelqIePK9b+7TpTKkL4CPNVPWIsOSX5 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 851 Lines: 18 On Mon, 4 Sep 2017, Roman Gushchin wrote > To address these issues, cgroup-aware OOM killer is introduced. You are missing a major issue here. Processes may have allocation constraints to memory nodes, special DMA zones etc etc. OOM conditions on such resource constricted allocations need to be dealt with. Killing processes that do not allocate with the same restrictions may not do anything to improve conditions. > But a user can change this behavior by enabling the per-cgroup > oom_kill_all_tasks option. If set, it causes the OOM killer treat > the whole cgroup as an indivisible memory consumer. In case if it's > selected as on OOM victim, all belonging tasks will be killed. Sounds good in general. Unless the cgroup or processes therein run out of memory due to memory access restrictions. How do you detect that and how it is handled?