Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp362814pxb; Wed, 23 Mar 2022 20:41:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyobe0AoIAT5m4DUxn/KXl67ccRb/O/2iKSmen458qtawkz6h1IRihOfLHJy5Q0PKIM2PkV X-Received: by 2002:a05:6a00:1a4a:b0:4f7:be32:3184 with SMTP id h10-20020a056a001a4a00b004f7be323184mr3228565pfv.65.1648093288554; Wed, 23 Mar 2022 20:41:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648093288; cv=none; d=google.com; s=arc-20160816; b=yb/qAio/FGA4mDbZtnCarBOsFKBdVYCYEUVp8W8m+6JauB/NS71H5eoxPncqX3eeCD AoGM9tLjpz3rroPjofYxHFPHDsaTyThc8iG55vWxITpD32daCFhh3ziXfVsr+lRpHaHg kBqYExdqD1Qj7g8/Z+cz3PovBEtYrkQDkqRG6bM/b+Q/1M42CyQ9b4EDYdbAp3CgtqTf pRV+KOz5jkzsQNTceUnT+jK7ShEZ4npove4zjdbAfvAmx3M/yFCg0iySZJqvx3B3FQDu sb01qtQoj3kYr+u2ILCPkF072x468I+B85FvGQRC6qR4R1n6bPCwuVgkWbTjpUukIO6y W2zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:dkim-signature:date; bh=XY5kMoTXHmqmiVy2HYgdwsUIAUgV0f+WD3Zq9NZ1rig=; b=KM8PPBzHJcwdRkVte9FyATdZE/B56qwwrgvCl1ObR7MScU/fxQ20mNUHULbuWfmoyw oWFKkoHlrx+tVmuuvjLIfzFyAU32cdPJ0qKvXFKbeHam2SxkpuJaMi3RjK4eSmaoz7a0 34fb9aSfoYbaiy8FTFP6q6n4ByW7BsI6zB7uj6iNlFqy4D9B+CnIGnT0tEn59OKht2uC AHNQIlwMNgwWmThKCVFzYVy/hrCtxnXm0YSXjg/TwyKH0ZdgF8zFxJRZi8frz5Pjh3Qs i9SbEPqO2kVWOnDYbB41b3mrCPiguxPRhd5YzlYkJ3BhcgU23Wi8BVd3qsEXf+YoUebx 7+gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=tIkhyUwC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w22-20020a1709027b9600b00153b2d1653fsi5162817pll.327.2022.03.23.20.40.46; Wed, 23 Mar 2022 20:41:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=tIkhyUwC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344982AbiCWVqH (ORCPT + 99 others); Wed, 23 Mar 2022 17:46:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41286 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239441AbiCWVqG (ORCPT ); Wed, 23 Mar 2022 17:46:06 -0400 Received: from out1.migadu.com (out1.migadu.com [IPv6:2001:41d0:2:863f::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 561B18CD99; Wed, 23 Mar 2022 14:44:35 -0700 (PDT) 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 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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!