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 B0A36C433F5 for ; Thu, 12 May 2022 17:27:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 186886B0074; Thu, 12 May 2022 13:27:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 136936B0075; Thu, 12 May 2022 13:27:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00C066B0078; Thu, 12 May 2022 13:27:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E1F1D6B0074 for ; Thu, 12 May 2022 13:27:41 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id AAD8F120780 for ; Thu, 12 May 2022 17:27:41 +0000 (UTC) X-FDA: 79457773122.11.798C6D6 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf20.hostedemail.com (Postfix) with ESMTP id 43E041C0003 for ; Thu, 12 May 2022 17:27:31 +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-out2.suse.de (Postfix) with ESMTPS id CDD141F8EF; Thu, 12 May 2022 17:27:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1652376459; 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=7XEGm/1PGoEXcO1HFP5KFYVz2HoDo+VVY6EzV48qjEY=; b=FzNR/9sgSrYP2DPIDbJYhi2A7TQZTkeEClVE8X88trBQ+zDeTp6YXcGexdIzHN9WVt1CXT 6ppZ2fr+wNOvNGpQiGz6QiiimHTY0fyVoPFyBeCsw0Wxl9Pe77+R+JdNfKLcpjL+emZ331 gZhmVXUA0C5FWdFhgV4XQ8ieop+pvys= 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 9396713ABE; Thu, 12 May 2022 17:27:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id zMdGI4tDfWJwJQAAMHmgww (envelope-from ); Thu, 12 May 2022 17:27:39 +0000 Date: Thu, 12 May 2022 19:27:38 +0200 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Johannes Weiner Cc: Andrew Morton , David Vernet , 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 , Chris Down Subject: Re: [PATCH v2 2/5] cgroup: Account for memory_recursiveprot in test_memcg_low() Message-ID: <20220512172738.GB16096@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> <20220429092620.GA23621@blackbody.suse.cz> <20220506164015.fsdsuv226nhllos5@dev0025.ash9.facebook.com> <20220509174424.e43e695ffe0f7333c187fba8@linux-foundation.org> <20220510174341.GC24172@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: jc4eur9rjw6rrwnebeteudb446jo64g6 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 43E041C0003 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="FzNR/9sg"; spf=pass (imf20.hostedemail.com: domain of mkoutny@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspam-User: X-HE-Tag: 1652376451-896904 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 Wed, May 11, 2022 at 01:53:05PM -0400, Johannes Weiner wrote: > Can you indeed elaborate on the problem you see with low events? My mistake. I realized I was testing on a system without memory_recursiveprot enabled. Therefore I saw no events in children with memory.low=0. However, it also means that my previous evaluation of the "simple" fix (dropping the SWAP_CLUSTER_MAX rounding) was incorrect and it actually doesn't resolve the problem of two differently active siblings I posted earlier. > So your proposed patch looks like the right thing to do to me. And I > would ack it, but please do explain your concerns around low event > reporting after it. I retract it (at least for now), it doesn't really help. It can be seen (after application) [1] that once (low) protected memory is opened for reclaim, the sibling proportions change suddenly (neither sibling is protected during sc->memcg_low_reclaim, however, the formerly protected suddenly provides good supply of reclaimable pages). OTOH, without memory_recursiveprot [2], the elow growth of the victim sibling is absent and situation stabilizes with only partial reclaim from the (explicitly) protected sibling. In both variants (recursive/non-recursive) the parent ends up with same amount of unreclaimed memory, however, the gradual tranfer of elow with the recursive protection is undesired. (I'm only thinking how to solve it simply.) Michal [1] https://bugzilla.suse.com/attachment.cgi?id=858869 [2] https://bugzilla.suse.com/attachment.cgi?id=858870