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 93626C4332F for ; Mon, 9 May 2022 15:10:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB1A46B0072; Mon, 9 May 2022 11:10:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D61E66B0073; Mon, 9 May 2022 11:10:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C02726B0074; Mon, 9 May 2022 11:10:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B218A6B0072 for ; Mon, 9 May 2022 11:10:14 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 88D1A30ADD for ; Mon, 9 May 2022 15:10:14 +0000 (UTC) X-FDA: 79446540348.03.139CC20 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) by imf25.hostedemail.com (Postfix) with ESMTP id 03E1CA009F for ; Mon, 9 May 2022 15:09:56 +0000 (UTC) Received: by mail-qv1-f46.google.com with SMTP id eq14so10644817qvb.4 for ; Mon, 09 May 2022 08:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=4MK5Z5duMa87oHfTgQRev3JJqnSTwXWH5fVcV34L7dM=; b=l+MeEY8PFGfskD3FsCOlvSab9XgG1oPg/iynQwlXTFrp/alh8KkZYehnFpakdk+2y6 jKiO9k7kOkYPU29eqCecdB6DUs7C1PNR2Ev/yXH8aw2fNbvvy9l/YtVVbQahxBmKHV76 m/29e1REy8tS9WU0KLk8b+3BVI/mNjWrTP6+evBbdVEgKqv6XW/bg6XuZXwtDZOlT/Hf fQDDLvknV+r9yrtTnJrM1LaVNhutiu1tHOYhsUCqSsvBfrOsnuazqm6H4R9vbMlZoy6J 3FHixuJyOBVhZ7sr+23dJSEwCWrY0/paq2Z0MtQCeTzBTz5qsjpX6Mro80MNDaSvgMJT nGGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=4MK5Z5duMa87oHfTgQRev3JJqnSTwXWH5fVcV34L7dM=; b=mIm3nvTFNqpZ3HZQI858kPWVb99R8sQqRgrYUlwYgc38SvTuNc694YWJcSjUYUxj5N StpPiWj4NELCG6V313QDpJTYlyTdCN3PDyej0+aXTTixui6Pmpto4WeJJ+DWBKeIgKlR xFuiOtdSAlX7OjYHXDzlzU5/sf+t+cr0jTWchlW2Y2+pLedTgC70i5tHMF7fnmT6oh6G 64/wQdfIm0AQPXeP0GxqwsaST4ptnfaEuJi2fZYUXJxFqpy76TKoUNn8uxl11QGncBeG HHyrlCaTYcREfnYn2qGsYgqa/n6wnOU0TO07LFCKPamSkZ7sJg8NgtYr9v5rW8UD7fRp vzOA== X-Gm-Message-State: AOAM530TDi2gjGot8wQfxmxpsxrYO+Q81uKEPvceKJ2ZjZOCkVelXsSQ rcCBPX+jYvDvUHFmF5+fododMQ== X-Google-Smtp-Source: ABdhPJyrdOc5aCCIZRy/kHlzbTcozCuWKwx16OcowRT8isOJHxngJEvIX80+q3pDpiFPpK3GOzPE2A== X-Received: by 2002:ad4:5504:0:b0:456:35e0:1968 with SMTP id az4-20020ad45504000000b0045635e01968mr13517316qvb.126.1652109012556; Mon, 09 May 2022 08:10:12 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:538c]) by smtp.gmail.com with ESMTPSA id n1-20020ac81e01000000b002f39b99f679sm7883463qtl.19.2022.05.09.08.10.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 08:10:11 -0700 (PDT) Date: Mon, 9 May 2022 11:09:15 -0400 From: Johannes Weiner To: David Vernet Cc: Michal =?iso-8859-1?Q?Koutn=FD?= , akpm@linux-foundation.org, tj@kernel.org, roman.gushchin@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, mhocko@kernel.org, shakeelb@google.com, kernel-team@fb.com, Richard Palethorpe Subject: Re: [PATCH v2 2/5] cgroup: Account for memory_recursiveprot in test_memcg_low() Message-ID: References: <20220423155619.3669555-1-void@manifault.com> <20220423155619.3669555-3-void@manifault.com> <20220427140928.GD9823@blackbody.suse.cz> <20220429010333.5rt2jwpiumnbuapf@dev0025.ash9.facebook.com> <20220429092620.GA23621@blackbody.suse.cz> <20220506164015.fsdsuv226nhllos5@dev0025.ash9.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220506164015.fsdsuv226nhllos5@dev0025.ash9.facebook.com> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 03E1CA009F Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=cmpxchg-org.20210112.gappssmtp.com header.s=20210112 header.b=l+MeEY8P; spf=pass (imf25.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.46 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org X-Rspam-User: X-Stat-Signature: gzokf5d8tiqp51t7sd83u3zq39jejb98 X-HE-Tag: 1652108996-969622 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, May 06, 2022 at 09:40:15AM -0700, David Vernet wrote: > Sorry for the delayed reply, Michal. I've been at LSFMM this week. > > On Fri, Apr 29, 2022 at 11:26:20AM +0200, Michal Koutný wrote: > > I still think that the behavior when there's no protection left for the > > memory.low == 0 child, there should be no memory.low events (not just > > uncounted but not happening) and test should not accept this (even > > though it's the current behavior). > > That's fair. I think part of the problem here is that in general, the > memcontroller itself is quite heuristic, so it's tough to write tests that > provide useful coverage while also being sufficiently flexible to avoid > flakiness and over-prescribing expected behavior. In this case I think it's > probably correct that the memory.low == 0 child shouldn't inherit > protection from its parent under any circumstances due to its siblings > overcommitting the parent's protection, but I also wonder if it's really > necessary to enforce that. If you look at how much memory A/B/E gets at the > end of the reclaim, it's still far less than 1MB (though should it be 0?). > I'd be curious to hear what Johannes thinks. We need to distinguish between what the siblings declare and what they consume. My understanding of the issue you're raising, Michal, is that protected siblings start with current > low, then get reclaimed slightly too much and end up with current < low. This results in a tiny bit of float that then gets assigned to the low=0 sibling; when that sibling gets reclaimed regardless, it sees a low event. Correct me if I missed a detail or nuance here. But unused float going to siblings is intentional. This is documented in point 3 in the comment above effective_protection(): if you use less than you're legitimately claiming, the float goes to your siblings. So the problem doesn't seem to be with low accounting and event generation, but rather it's simply overreclaim. It's conceivable to make reclaim more precise and then tighten up the test. But right now, David's patch looks correct to me.