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 ABAAAC47258 for ; Tue, 23 Jan 2024 09:33:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A6946B0071; Tue, 23 Jan 2024 04:33:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 157466B0074; Tue, 23 Jan 2024 04:33:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 046236B007E; Tue, 23 Jan 2024 04:33:41 -0500 (EST) 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 E949E6B0071 for ; Tue, 23 Jan 2024 04:33:41 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6C1EEC0A62 for ; Tue, 23 Jan 2024 09:33:41 +0000 (UTC) X-FDA: 81710063442.30.238495A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf24.hostedemail.com (Postfix) with ESMTP id 0D1FE180011 for ; Tue, 23 Jan 2024 09:33:38 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=S+BrXl9K; dkim=pass header.d=suse.com header.s=susede1 header.b=S+BrXl9K; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706002419; a=rsa-sha256; cv=none; b=IRSMEzLUqIJ+jbbTAx9qqowV8pKXjY++rGaJmuCn90W6lqR4QRVXx45mPjaY1cepiP818b YFcaTN29g2ButN4sZTyAB1IHqsggiC7rMONWEV0zTQko1Ez+hrZ3Q56QwKzD9qy5tZU3Yh 5cPBNn0TWU5zEwhwPRlodzTrvVXLyH4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=S+BrXl9K; dkim=pass header.d=suse.com header.s=susede1 header.b=S+BrXl9K; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706002419; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vr0dVSL74POTu+Iy/t8VsndcOHjm5FnK2rIR21aIjBA=; b=y6L/3UWMrvxsJHzYlxxymZ4O4HpFZeV55DaZJBN/P+TRN/O53OEcMp+9/RzD+NTZTW6QRi dEL1BZGpeLFzsOlThKpsxKYBtZsqdD3MXLOeDNieyIuyyqw37A+Z/kjFb9yAnPz5cCov4l q/E7h4zmpInLZvx3c7j0/j8ZpR1eQy8= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3249622177; Tue, 23 Jan 2024 09:33:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1706002417; 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=vr0dVSL74POTu+Iy/t8VsndcOHjm5FnK2rIR21aIjBA=; b=S+BrXl9K9p1cn9yvSqLBO6VScZ2ywrf6is1PxTTlOrOQLKR/o1eBgNPpxkLlrCuQiXFQQl ppba9WHp4P1Rk+Xl+nS5t5H/PqltWHfRSpGhUke8SVx0Y9i2fBBGEWEMzWKRzzqxG8e32f 9YiuDQWiNDXvvemyB6ndXo393rAodMo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1706002417; 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=vr0dVSL74POTu+Iy/t8VsndcOHjm5FnK2rIR21aIjBA=; b=S+BrXl9K9p1cn9yvSqLBO6VScZ2ywrf6is1PxTTlOrOQLKR/o1eBgNPpxkLlrCuQiXFQQl ppba9WHp4P1Rk+Xl+nS5t5H/PqltWHfRSpGhUke8SVx0Y9i2fBBGEWEMzWKRzzqxG8e32f 9YiuDQWiNDXvvemyB6ndXo393rAodMo= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 13D05136A4; Tue, 23 Jan 2024 09:33:37 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id bXbOAfGHr2VMBwAAD6G6ig (envelope-from ); Tue, 23 Jan 2024 09:33:37 +0000 Date: Tue, 23 Jan 2024 10:33:36 +0100 From: Michal Hocko To: "T.J. Mercier" Cc: Johannes Weiner , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , android-mm@google.com, yuzhao@google.com, yangyifei03@kuaishou.com, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" Message-ID: References: <20240121214413.833776-1-tjmercier@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240121214413.833776-1-tjmercier@google.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0D1FE180011 X-Stat-Signature: 1z3jscmu6jjrmoxwhp5ot3wurbttep69 X-Rspam-User: X-HE-Tag: 1706002418-159605 X-HE-Meta: U2FsdGVkX18WaAIoo+tBmtEI38PNDbYE4LEB8jZQVa5esS6+OQKNtIEBjitAiYpN0JZh38rj+hgT7xgTsh2oMaVQ6XtsMbWb2t37MJfiMOGCh+mckrAjSUAoMpSYVccFhiRAA65obwK9Yph4dZlCFS1wk8BQJ6N3P7+qsdhLaOCbz/lR/BHp639wkmLSHY048nKqCJZMWELM0qdNzez+BZNwXpuVKq5vTe141xMNiNmSity0KIRT+2P1EObYIW17DhYep05DkoHepmRFcu/QC0/SGfOcQWhwFp1uAVVFEEk6EF+pr6YFHfvMjuO9W/xUHCj9beMdDgELlSM/VktI9o6x3SvEexrwTfN0B9s+aNsrF4VgyO0nEM4YWNzW0g1BTQmoDA+K9ZVY9YHS8O196lS0gcPCCeDDa6m9VvQxKlpOWYfaSwnfOoTT+YW76F58IyMuuxh9gA6iww5EHOv9voKsSe+fIS7rtsqOs1eESIC0ULYZaAmG5kWFysaoD9Wju14cKrXgWBUScoGYKBem/SpDtVQeqU0xgSjcpxkoogyzrPsJIjAtIvQlsXnAuPF5Gzp03eMhv2Wkjy+En8pOoc+LMjYXCVb31dPWf+9Ju7HwKkJx9beP+P56iM7SsG8kcPDLfOuiEdUj6Co2ZIql71dXcCWLJ4ZJwYrKAyIuh0jqvTxT2v5GsqL8u1aj0JFtXSOHR2HWr7sd379tR087nvEBUlpcORKWqiY4LNNki8GsSZ7JInudXNOuQUz7bQn0OLSObYCBFUnVBnaRDHVv369O0gnn/y5Cf8ks/2dvsVNr0U6WYI67upGxea3N9yvaWPwyeAYl+TQNCUVotTfPfKuXiPJ/nEHzRB/YU8Yidku5LFF39mszplW04Zps3WlByFm1EQpLC5/sGdCoJq6X+5cvpyEZ++iGQxZO5+wIseXgbVyhSOwvmvHE/v6/iZPrmu1cBXRze357kHxcdoR qrOY9J5l UKKvYcdi52mNkLbLPZslEuN1hS4//lWbTkJxrITJhMrqPl/T+8cJxx+mfzNGuEBLj9oOSmuyWlv/5dRjVucgfITR7yefCUc63cgLxmtFv3R8QxVfiu8bJc2jzODHfvRRsWyFiEoesP+2GZHqmOJxfXN3Q2TtDzvJFcUrEIvgqh0JvlLcTYFdBJYTSAClzwCuT+L7rr7qxKkMTE45fESrRFOTDQtyVfS2Po8WgG3oU8eAKj7Y= 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: List-Subscribe: List-Unsubscribe: On Sun 21-01-24 21:44:12, T.J. Mercier wrote: > This reverts commit 0388536ac29104a478c79b3869541524caec28eb. > > Proactive reclaim on the root cgroup is 10x slower after this patch when > MGLRU is enabled, and completion times for proactive reclaim on much > smaller non-root cgroups take ~30% longer (with or without MGLRU). What is the reclaim target in these pro-active reclaim requests? > With > root reclaim before the patch, I observe average reclaim rates of > ~70k pages/sec before try_to_free_mem_cgroup_pages starts to fail and > the nr_retries counter starts to decrement, eventually ending the > proactive reclaim attempt. Do I understand correctly that the reclaim target is over estimated and you expect that the reclaim process breaks out early> > After the patch the reclaim rate is > consistently ~6.6k pages/sec due to the reduced nr_pages value causing > scan aborts as soon as SWAP_CLUSTER_MAX pages are reclaimed. The > proactive reclaim doesn't complete after several minutes because > try_to_free_mem_cgroup_pages is still capable of reclaiming pages in > tiny SWAP_CLUSTER_MAX page chunks and nr_retries is never decremented. I do not understand this part. How does a smaller reclaim target manages to have reclaimed > 0 while larger one doesn't? > The docs for memory.reclaim say, "the kernel can over or under reclaim > from the target cgroup" which this patch was trying to fix. Revert it > until a less costly solution is found. > > Signed-off-by: T.J. Mercier > --- > mm/memcontrol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index e4c8735e7c85..cee536c97151 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -6956,8 +6956,8 @@ static ssize_t memory_reclaim(struct kernfs_open_file *of, char *buf, > lru_add_drain_all(); > > reclaimed = try_to_free_mem_cgroup_pages(memcg, > - min(nr_to_reclaim - nr_reclaimed, SWAP_CLUSTER_MAX), > - GFP_KERNEL, reclaim_options); > + nr_to_reclaim - nr_reclaimed, > + GFP_KERNEL, reclaim_options); > > if (!reclaimed && !nr_retries--) > return -EAGAIN; > -- > 2.43.0.429.g432eaa2c6b-goog > -- Michal Hocko SUSE Labs