Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp380951ybx; Mon, 4 Nov 2019 22:12:01 -0800 (PST) X-Google-Smtp-Source: APXvYqydXfS+ZH4eNUi5d6nQE9ZrKRErgf3VkT9WkCec7AfBRpSr4BkeaVDHUgbBU1yL20ujEESS X-Received: by 2002:aa7:d888:: with SMTP id u8mr23223912edq.144.1572934321164; Mon, 04 Nov 2019 22:12:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572934321; cv=none; d=google.com; s=arc-20160816; b=LENB+LM+X9SL7PKVoIcbsWpzJHOwMyMkPjkl2Ia/EMupC+GQp7BhARuN7RFMkkb7i3 J5yF65kBdZTPdNccuJnP8qtF26vwVdKkqfQIAbwuVgMpxe8hPFZnzKk0LXOS1P+OQUHg NHk8tl6F0RZzeWxS/+bL6OOaXQKI2HQon71v6MFzpezltfBGSLPMg0Y8rRRjTxBWWnL2 OwpkOcd7p7sPwuOnHkLx6XS7Owh3CFlSY6WYV51QFwT0QEuyYTd7OveNngzFcFv1ckb0 hvG/kHVamXra1e+K9iMMxXQtv1u3G8glZFJmikBj+EuPiAcLGtYUvww11OVjq64p0qDd ziSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/qZ3VRixgRANbCT1SLbRc6vv/xmOfwb7ztRHv4YqeCs=; b=D31+HHG8XtYgsXucQ8hyL/hikJVEPopYQh4HEP+B1DIqo7tqDeASIlZbeVPevJQu9z FXkGbJ/6EotwnMiwaun7Hc4pduYKOqKVyebZ8oZIY81fGVu+LioToruFo20szMvatRCD sO0VZjk3ztjHKjmn4xuxEBXmHrOSoyEzYA4XDOEqsZlJAT1IruRAf/pjkt83o8uz/0Xo GYEXRpVfO9voZgbm6VJA+BimaS/0FYQNFXLADVGVTQavXb26HDGTZXaBsjuK8dNrKJKd YX2d0Qs9HN4jGa8ehlesJ0szAMDkbZD+HC5Xb9noFAoKy8iK6A/Rb+YUtdde7DwkfSTP wGxg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3si9867583edn.202.2019.11.04.22.11.35; Mon, 04 Nov 2019 22:12:01 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387597AbfKEGKC (ORCPT + 99 others); Tue, 5 Nov 2019 01:10:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:39870 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387454AbfKEGKC (ORCPT ); Tue, 5 Nov 2019 01:10:02 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 75FB4B160; Tue, 5 Nov 2019 06:10:00 +0000 (UTC) Date: Tue, 5 Nov 2019 07:09:59 +0100 From: Michal Hocko To: Konstantin Khlebnikov Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH] mm/memcontrol: update documentation about invoking oom killer Message-ID: <20191105060959.GA22672@dhcp22.suse.cz> References: <157270779336.1961.6528158720593572480.stgit@buzz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <157270779336.1961.6528158720593572480.stgit@buzz> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 02-11-19 18:16:33, Konstantin Khlebnikov wrote: > Since commit 29ef680ae7c2 ("memcg, oom: move out_of_memory back to the > charge path") memcg invokes oom killer not only for user page-faults. > This means 0-order allocation will either succeed or task get killed. > > Fixes: 8e675f7af507 ("mm/oom_kill: count global and memory cgroup oom kills") Is this really appropriate? 8e675f7af507 was correct at the time. It was 29ef680ae7c2 that hasn't updated the documentation. I would just drop the Fixes tag. > Signed-off-by: Konstantin Khlebnikov > --- > Documentation/admin-guide/cgroup-v2.rst | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > index 5361ebec3361..eb47815e137b 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -1219,8 +1219,13 @@ PAGE_SIZE multiple when read back. > > Failed allocation in its turn could be returned into > userspace as -ENOMEM or silently ignored in cases like > - disk readahead. For now OOM in memory cgroup kills > - tasks iff shortage has happened inside page fault. > + disk readahead. > + > + Before 4.19 OOM in memory cgroup killed tasks iff I would go with Kernels between 3.12 and 4.19 invoked the oom killer only if shortage has happened inside page fault. > + shortage has happened inside page fault, random > + syscall may fail with ENOMEM or EFAULT. Since 4.19 > + failed memory cgroup allocation invokes oom killer and > + keeps retrying until it succeeds. > > This event is not raised if the OOM killer is not > considered as an option, e.g. for failed high-order -- Michal Hocko SUSE Labs