From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CFBFC432BE for ; Tue, 31 Aug 2021 15:57:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D968260F56 for ; Tue, 31 Aug 2021 15:57:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D968260F56 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 68D6C940007; Tue, 31 Aug 2021 11:57:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63D518D0001; Tue, 31 Aug 2021 11:57:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DD77940007; Tue, 31 Aug 2021 11:57:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 3B1A98D0001 for ; Tue, 31 Aug 2021 11:57:08 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id DAAD6269B4 for ; Tue, 31 Aug 2021 15:57:07 +0000 (UTC) X-FDA: 78535829694.03.4B34241 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf20.hostedemail.com (Postfix) with ESMTP id 85E87D0000A9 for ; Tue, 31 Aug 2021 15:57:07 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 3805F221CB; Tue, 31 Aug 2021 15:57:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1630425426; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r6kHgxX95RLos0Aa70DLyOZnKO3e+ri121ddJA4qCzQ=; b=jumbj38gN7MJUIRvplpPEztTc5adYZ0rvxNxWfgRFPWAyTbWbmrwCmaUJMQIV/aikQE60I kyKtrRFL/FtD0Qv1x5SmB7E5U/HrvlLZzv+Uq6AoESmvTaFCEYCSShNgY08SYhh7611mLC Uit4e/6tEBfKxriI15oGEZ/Y53+WHu0= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id E4605A3B9F; Tue, 31 Aug 2021 15:57:05 +0000 (UTC) Date: Tue, 31 Aug 2021 17:57:02 +0200 From: Michal Hocko To: Feng Tang Cc: linux-mm@kvack.org, Andrew Morton , Christian Brauner , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm/oom: detect and kill task which has allocation forbidden by cpuset limit Message-ID: References: <1630399085-70431-1-git-send-email-feng.tang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1630399085-70431-1-git-send-email-feng.tang@intel.com> Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=jumbj38g; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 85E87D0000A9 X-Stat-Signature: 8c3765j18fkquacx9hft9hxm1nb5radi X-HE-Tag: 1630425427-27424 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 31-08-21 16:38:05, Feng Tang wrote: > There was report that starting an Ubuntu in docker while using cpuset > to bind it to movlabe nodes (a node only has movable zone, like a node > for hotplug or a PMEM node in normal usage) will fail due to memory > allocation failure, and then OOM is involved and many other innocent > processes got killed. It can be reproduced with command: > $docker run -it --rm --cpuset-mems 4 ubuntu:latest bash -c > "grep Mems_allowed /proc/self/status" (node 4 is a movable node) Is there any valid usecase to allow cpusets to be configured only to movable nodes? Wouldn't it be better to simply disallow such a setup? I do understand that we usually allow people to shoot their feet but this one has some wider consequences. > The reason is, in the case, the target cpuset nodes only have movable > zone, while the creation of an OS in docker sometimes needs to allocate > memory in non-movable zones (dma/dma32/normal) like GFP_HIGHUSER, and > the cpuset limit forbids the allocation, then out-of-memory killing is > involved even when normal nodes and movable nodes both have many free > memory. > > We've posted patches to LKML trying to make the usage working by > loosening the check, which is not agreed as the cpuset binding should > be respected, and should not be bypassed [1] > > But still there is another problem, that when the usage fails as it's an > mission impossible due to the cpuset limit, the allocating should just > be killed first, before any other innocent processes get killed. I do not like this solution TBH. We know that that it is impossible to satisfy the allocation at the page allocator level so dealing with it at the OOM killer level is just a bad layering and a lot of wasted cycles to reach that point. Why cannot we simply fail the allocation if cpusets filtering leads to an empty zone intersection? -- Michal Hocko SUSE Labs