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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B864C433EF for ; Wed, 23 Mar 2022 21:44:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7996D6B0072; Wed, 23 Mar 2022 17:44:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 721516B0073; Wed, 23 Mar 2022 17:44:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57D866B0074; Wed, 23 Mar 2022 17:44:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 43CB76B0072 for ; Wed, 23 Mar 2022 17:44:35 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0806820A79 for ; Wed, 23 Mar 2022 21:44:35 +0000 (UTC) X-FDA: 79276980510.04.8943141 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf23.hostedemail.com (Postfix) with ESMTP id 3679D14003A for ; Wed, 23 Mar 2022 21:44:34 +0000 (UTC) Date: Wed, 23 Mar 2022 14:44:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1648071872; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XY5kMoTXHmqmiVy2HYgdwsUIAUgV0f+WD3Zq9NZ1rig=; b=tIkhyUwCj21h679R74DUEqJYdwnu60YleSAUF//3fNmiqt+PYVpSZRINK+Jhl6RkUQIqws q7cnt3gzzC1vcMomxCfEn/iGbAeykyC28Ki3sc7uHV5FoNBJJar3asnQl+BeYWwl12EbDB hjQEpEuUhpu0HrV0NM+eJwzG3K2B00c= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Richard Palethorpe , Andrew Morton , Shakeel Butt , Michal Hocko , Vlastimil Babka , "Matthew Wilcox (Oracle)" , Muchun Song , Johannes Weiner , Yang Shi , Suren Baghdasaryan , Tejun Heo , Chris Down Subject: Re: [RFC PATCH] mm: memcg: Do not count memory.low reclaim if it does not happen Message-ID: References: <20220322182248.29121-1-mkoutny@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220322182248.29121-1-mkoutny@suse.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=tIkhyUwC; spf=pass (imf23.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Stat-Signature: koaxfjoow9dz6w4fus8zok6pwy6xb1wp X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3679D14003A X-HE-Tag: 1648071874-75432 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, Mar 22, 2022 at 07:22:48PM +0100, Michal Koutny wrote: > This was observed with memcontrol selftest/new LTP test but can be also > reproduced in simplified setup of two siblings: > > `parent .low=50M > ` s1 .low=50M .current=50M+ε > ` s2 .low=0M .current=50M > > The expectation is that s2/memory.events:low will be zero under outer > reclaimer since no protection should be given to cgroup s2 (even with > memory_recursiveprot). > > However, this does not happen. The apparent reason is that when s1 is > considered for (proportional) reclaim the scanned proportion is rounded > up to SWAP_CLUSTER_MAX and slightly over-proportional amount is > reclaimed. Consequently, when the effective low value of s2 is > calculated, it observes unclaimed parent's protection from s1 > (ε-SWAP_CLUSTER_MAX in theory) and effectively appropriates it. > The effect is slightly regularized protection (workload dependent) > between siblings and misreported MEMCG_LOW event when reclaiming s2 with > this protection. > > Fix the behavior by not reporting breached memory.low in such > situations. (This affects also setups where all siblings have > memory.low=0, parent's memory.events:low will still be non-zero when > parent's memory.low is breached but it will be reduced by the events > originated in children.) > > Fixes: 8a931f801340 ("mm: memcontrol: recursive memory.low protection") > Reported-by: Richard Palethorpe > Link: https://lore.kernel.org/all/20220321101429.3703-1-rpalethorpe@suse.com/ > Signed-off-by: Michal Koutný Hi Michal! Does it mean that in the following configuration: `parent .low=50M ` s1 .low=0M .current=50M ` s2 .low=0M .current=50M there will be no memory.events::low at all? (assuming the recursive thing is on) Thanks!