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 14D70C433EF for ; Fri, 29 Apr 2022 09:26:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C0A46B0074; Fri, 29 Apr 2022 05:26:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 470196B0075; Fri, 29 Apr 2022 05:26:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35F916B0078; Fri, 29 Apr 2022 05:26:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 26F266B0074 for ; Fri, 29 Apr 2022 05:26:24 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CD006218A9 for ; Fri, 29 Apr 2022 09:26:23 +0000 (UTC) X-FDA: 79409385846.16.9B6B55D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf08.hostedemail.com (Postfix) with ESMTP id 32C6F160013 for ; Fri, 29 Apr 2022 09:26:16 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B4C9921870; Fri, 29 Apr 2022 09:26:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1651224381; 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=U29ZMPPzFK4uUEyUYePHiz2qlt3Ri7SCZ7aNiH026UY=; b=IGPyVwbIILUdzwZFwC6tg5ufsIZXP5ClacMvrcvkQiCZaeUgVRAYMM/AoNO9PpHjD/AEcL fOWpgPD83vJ1gjAAlqWmAdKmqOLaAsi5QlzP+Y1N3FfIUGIGGIZFJNt++GwMtNRmpzL3Rs N46aQwwVuCxWp71FRvxzu2n0+VXMq3Q= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 7D51713446; Fri, 29 Apr 2022 09:26:21 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 903IHT2va2LwAgAAMHmgww (envelope-from ); Fri, 29 Apr 2022 09:26:21 +0000 Date: Fri, 29 Apr 2022 11:26:20 +0200 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: David Vernet Cc: akpm@linux-foundation.org, tj@kernel.org, roman.gushchin@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, hannes@cmpxchg.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: <20220429092620.GA23621@blackbody.suse.cz> References: <20220423155619.3669555-1-void@manifault.com> <20220423155619.3669555-3-void@manifault.com> <20220427140928.GD9823@blackbody.suse.cz> <20220429010333.5rt2jwpiumnbuapf@dev0025.ash9.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220429010333.5rt2jwpiumnbuapf@dev0025.ash9.facebook.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 32C6F160013 X-Stat-Signature: kzoyzo531hb6one6orxz16ptw436rynn Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=IGPyVwbI; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf08.hostedemail.com: domain of mkoutny@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mkoutny@suse.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1651224376-16663 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 Thu, Apr 28, 2022 at 06:03:33PM -0700, David Vernet wrote: > but my interpretation of the rest of that discussion with Roman is > that we haven't yet decided whether we don't want to propagate > memory.low events from children cgroups with memory.low == 0. Or at > the very least, some more justification was requested on why not > counting such events was prudent. I'm not a fan of that original proposal of mine anymore (to be more precise, of _only_ that patch, there's still the RFCness reason 1) to consider). As I shared with the last reply there, there's a problem in the behavior which shouldn't be masked by filtering some events. > Would you be ok with merging this patch so that the cgroup selftests can > pass again based on the current behavior of the kernel, and we can then > revert the changes to test_memcg_low() later on if and when we decide that > we don't want to propagate memory.low events for memory.low == 0 children? 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). What might improve the test space would be to have two configs like Original one (simplified here) parent memory.low=50M memory.current=100M ` child1 memory.low=50M memory.current=50M ` child2 memory.low=0M memory.current=50M New one (checks events due to recursive protection) parent memory.low=50M memory.current=100M ` child1 memory.low=40M memory.current=50M ` child2 memory.low=0M memory.current=50M The second config assigns recursive protection to child2 and should therefore cause memory.low events in child2 (with memory_recursiveprot enabled of course). Or alternative new one (checks events due to recursive protection) parent memory.low=50M memory.current=100M ` child1 memory.low=0M memory.current=50M ` child2 memory.low=0M memory.current=50M HTH, Michal