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=-8.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 99A6EC38A2A for ; Fri, 8 May 2020 16:00:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 74D5320725 for ; Fri, 8 May 2020 16:00:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="qn0FXo6o" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 74D5320725 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CE9828E0005; Fri, 8 May 2020 12:00:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C99B88E0003; Fri, 8 May 2020 12:00:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAED18E0005; Fri, 8 May 2020 12:00:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id A001A8E0003 for ; Fri, 8 May 2020 12:00:24 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 58333180AD811 for ; Fri, 8 May 2020 16:00:24 +0000 (UTC) X-FDA: 76794013968.19.range00_5acc1e75cf41a X-HE-Tag: range00_5acc1e75cf41a X-Filterd-Recvd-Size: 4313 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 May 2020 16:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To: Subject:Sender:Reply-To:Content-ID:Content-Description; bh=NVwFrpHFPc9V5kgayHjz15+SJTwzcU4hIq0qYBGnEGI=; b=qn0FXo6oswTaaIEy2dd0+OzYvd 7+HkxgrTXQYH1jzmT6+IPqnXdMztANHC1nrHEO9RbIXLm4qLtj+Qnww2uFJJQdURM7RlkD3KXQrX7 5dsdpupZgcvw4wFckC1iiwHP4MVaokpmBGoRP8infNnM9m9otmSkN5+anv/pJd3AQ7n3/YMguzUeA 3I98i7edKgBwsVzprm0t1+R/gtDSKXdIhZCQce3Fw54j2NS088BEx4nghYD/I+QHzqhJVURpiWmuJ PedXdMfK/oJF6Qd502GLxkoJXH/fNsm0WNsblQGOv4GWd+7NcLhzap2hvoZnvD5lowztzo8sUbpK2 DjFcBNiQ==; Received: from [2601:1c0:6280:3f0::19c2] by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jX5Q8-0002vu-RN; Fri, 08 May 2020 16:00:16 +0000 Subject: Re: [PATCH] doc: cgroup: update note about conditions when oom killer is invoked To: Konstantin Khlebnikov , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton Cc: cgroups@vger.kernel.org, Roman Gushchin , Michal Hocko References: <158894738928.208854.5244393925922074518.stgit@buzz> From: Randy Dunlap Message-ID: Date: Fri, 8 May 2020 09:00:15 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <158894738928.208854.5244393925922074518.stgit@buzz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Hi, On 5/8/20 7:16 AM, Konstantin Khlebnikov wrote: > Starting from v4.19 commit 29ef680ae7c2 ("memcg, oom: move out_of_memory > back to the charge path") cgroup oom killer is no longer invoked only from > page faults. Now it implements the same semantics as global OOM killer: > allocation context invokes OOM killer and keeps retrying until success. > > Signed-off-by: Konstantin Khlebnikov > --- > Documentation/admin-guide/cgroup-v2.rst | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > index bcc80269bb6a..1bb9a8f6ebe1 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -1172,6 +1172,13 @@ PAGE_SIZE multiple when read back. > Under certain circumstances, the usage may go over the limit > temporarily. > > + In default configuration regular 0-order allocation always allocations > + succeed unless OOM killer choose current task as a victim. chooses > + > + Some kinds of allocations don't invoke the OOM killer. > + Caller could retry them differently, return into userspace > + as -ENOMEM or silently ignore in cases like disk readahead. > + > This is the ultimate protection mechanism. As long as the > high limit is used and monitored properly, this limit's > utility is limited to providing the final safety net. > @@ -1228,17 +1235,9 @@ PAGE_SIZE multiple when read back. > The number of time the cgroup's memory usage was > reached the limit and allocation was about to fail. > > - Depending on context result could be invocation of OOM > - killer and retrying allocation or failing allocation. > - > - 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. > - > This event is not raised if the OOM killer is not > considered as an option, e.g. for failed high-order > - allocations. > + allocations or if caller asked to not retry attempts. > > oom_kill > The number of processes belonging to this cgroup > thanks for updating the docs. -- ~Randy