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 6A107C433DB for ; Mon, 1 Mar 2021 12:24:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DA7A064E2E for ; Mon, 1 Mar 2021 12:24:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA7A064E2E Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 68F2A8D0066; Mon, 1 Mar 2021 07:24:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 63EEC8D0063; Mon, 1 Mar 2021 07:24:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 555598D0066; Mon, 1 Mar 2021 07:24:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 4077E8D0063 for ; Mon, 1 Mar 2021 07:24:47 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 07734181AF5C2 for ; Mon, 1 Mar 2021 12:24:47 +0000 (UTC) X-FDA: 77871224214.06.73590A6 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf20.hostedemail.com (Postfix) with ESMTP id 5F30A12E for ; Mon, 1 Mar 2021 12:24:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1614601485; 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=4e5MHeBWKUeRuWwrRN4F6v9QXnyfuUzg8gdWTjEdSqM=; b=Fv+Mhst1p1X2WCTKlqJ9E0maHOvbj9R5gK7b5JimaCIkQTFmdYibMYSzgt1pTbuU6xo65u LgdWWmvuZDMdP4UAU4UbjaWlfXNtFIeDklFRYjLOz7GZVsLWD74aI5ALutzCgF28FQxfMw 0LdXP4KRPF9ogyGljs12sUzVbfqOCV4= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 23E67AE30; Mon, 1 Mar 2021 12:24:45 +0000 (UTC) Date: Mon, 1 Mar 2021 13:24:39 +0100 From: Michal Hocko To: Yang Shi Cc: Johannes Weiner , Roman Gushchin , Shakeel Butt , Andrew Morton , Jonathan Corbet , Linux MM , Linux Kernel Mailing List Subject: Re: [PATCH] doc: memcontrol: add description for oom_kill Message-ID: References: <20210226021254.3980-1-shy828301@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: ydpems4p1bodb1h6knwoeemxchb1fn49 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5F30A12E Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614601486-539483 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 Fri 26-02-21 11:19:51, Yang Shi wrote: > On Fri, Feb 26, 2021 at 8:42 AM Yang Shi wrote: > > > > On Thu, Feb 25, 2021 at 11:30 PM Michal Hocko wrote: > > > > > > On Thu 25-02-21 18:12:54, Yang Shi wrote: > > > > When debugging an oom issue, I found the oom_kill counter of memcg is > > > > confusing. At the first glance without checking document, I thought it > > > > just counts for memcg oom, but it turns out it counts both global and > > > > memcg oom. > > > > > > Yes, this is the case indeed. The point of the counter was to count oom > > > victims from the memcg rather than matching that to the source of the > > > oom. Rememeber that this could have been a memcg oom up in the > > > hierarchy as well. Counting victims on the oom origin could be equally > > > > Yes, it is updated hierarchically on v2, but not on v1. I'm supposed > > this is because v1 may work in non-hierarchcal mode? If this is the > > only reason we may be able to remove this to get aligned with v2 since > > non-hierarchal mode is no longer supported. > > BTW, having the counter recorded hierarchically may help out one of > our usecases. We want to monitor the oom_kill for some services, but > systemd would wipe out the cgroup if the service is oom killed then > restart the service from scratch (it means create a brand new cgroup > with the same name). So this systemd behavior makes the counter > useless if it is not recorded hierarchically. Just to make sure I understand correctly. You have a setup where memcg for a service has a hard limit configured and it is destroyed when oom happens inside that memcg. A new instance is created at the same place of the hierarchy with a new memcg. Your problem is that the oom killed memcg will not be recorded in its parent oom event and the information will get lost with the torn down memcg. Correct? If yes then how do you tell which of the child cgroup was killed from the parent counter? Or is there only a single child? Anyway, cgroup v2 will offer the hierarchical behavior. Do you have any strong reasons that you cannot use v2? -- Michal Hocko SUSE Labs