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 92A20C47258 for ; Wed, 31 Jan 2024 17:51:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 287046B0071; Wed, 31 Jan 2024 12:51:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2374F6B0095; Wed, 31 Jan 2024 12:51:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D9006B0098; Wed, 31 Jan 2024 12:51:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EFB276B0071 for ; Wed, 31 Jan 2024 12:51:07 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A0B59A08CB for ; Wed, 31 Jan 2024 17:51:07 +0000 (UTC) X-FDA: 81740347374.25.ACC31A7 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf23.hostedemail.com (Postfix) with ESMTP id 8B440140022 for ; Wed, 31 Jan 2024 17:51:05 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=FjpMwiUB; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf23.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706723465; 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=4bSf7bOhErvUGe8OSqVrxrzA9YWlx2blDsXOWDY7bWc=; b=WhbXkj64S/cWxgaqrPuOQe+z2EiPMaf4xcKcUKCEADFEJLx+gv5LgRaPIsu4ZHC48TJVP6 1hVwvR4mXreL4fHFnNp164+ov+JoQ1bup3eckxfhZJHIHBfjaPrhu/hbnFaqVQhy6l9c2K NRj5FkeTYzhGqNJEnR6QFpK51g/+5i0= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=FjpMwiUB; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf23.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706723465; a=rsa-sha256; cv=none; b=oSRfHZIi52Vxw9/5iF6yzf9iQK0Jl5IkBFJGGFxCylWEaNCt7Mx+dPx/0WwjT0ck4kM3w+ cBtXVf+eVI90B0NH0b9uzk0uM3jZ5hR68iq6rkZKpYeB/7jOHrcjYEWfShW+nmtDU7MSc6 owBC0Xz/f7jMkKlGouWoIhYjvOlVqm8= Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-68c495ba558so302016d6.3 for ; Wed, 31 Jan 2024 09:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1706723464; x=1707328264; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4bSf7bOhErvUGe8OSqVrxrzA9YWlx2blDsXOWDY7bWc=; b=FjpMwiUBShmMo0MniKYWfYEkshsfEw4317Ejd62+2alEmoHrB1UW9W9PtW+31e+vG8 NkdhU33ryHlXH/7xUDJJtNexk02Lc75ai6WAzljUI8cQEYTMFEFXsSsDSJ6yAnJH/JoK lnbNCD6ew1uP6KpJsQ1tZIV4usbQsJ709QBHFGagi5j3gd2aruL/o17CKX1iI67VdkEY F3rWuhvu9JRqowHkst5mC01GPy6LXpjpQSLFoJuEbRc4u1oHDceeVF8oCUSCtMV3GGOc i20UWP9rCfke+dVOqKWqcL9ABlPFIioTdJa1d2JP3/yM/eijn64+TpNrj04nybbaaPMs Qjjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706723464; x=1707328264; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4bSf7bOhErvUGe8OSqVrxrzA9YWlx2blDsXOWDY7bWc=; b=qrtsWLmPdhjsTl7O4apfvBZRFKvDsNrdl6k4SOBKsvSq9+0k/LYi1//frnc2dxwYIy WEclpl45Ey49waymunZ4S4kdrGGyti/HMhp7TIYkiG/6QRrSnyJhV5tV0O1QgAcTsnsO gol8zElkRGhyVVpLFcSDrw7L8urzODwf/SJb7Jq7Xa7pT7N/GlhWcrWm5MkJgh2IoU0w 8LMiTiECuE3GnHcXs+FSua0MYO5O1NrenuomEtjDG9c1BYeqayE8UggfQfr/hZq/Oxwo lpl+Mb0uSMQGT5TpleAwcXk8dQG3AXbxD5bR2W7AS8vMFBqyShivcEwpJAn5Va7Xrgq7 lLvg== X-Gm-Message-State: AOJu0Yzjhe2yk9NoxNdEviH7GG00ETRT1e8BNWV35MyLJYnwuOEQY38n eDyPS+pL8xfuJ9bo0r0KJV2jbfTt1z4wh5EiYwlR6i9OZZukRelJlCzE0VVRTzU= X-Google-Smtp-Source: AGHT+IERMm2HQiYN0C0bnn9l10JBozKMVH89zidARxsELO0u19TRMBEjLyabrSRSAjMEl9ErpOfjNg== X-Received: by 2002:a05:6214:d87:b0:681:77d9:c405 with SMTP id e7-20020a0562140d8700b0068177d9c405mr2344836qve.33.1706723464493; Wed, 31 Jan 2024 09:51:04 -0800 (PST) Received: from localhost (2603-7000-0c01-2716-da5e-d3ff-fee7-26e7.res6.spectrum.com. [2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id s12-20020ad4500c000000b0068c510634d1sm2968358qvo.108.2024.01.31.09.51.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Jan 2024 09:51:04 -0800 (PST) Date: Wed, 31 Jan 2024 12:50:59 -0500 From: Johannes Weiner To: "T.J. Mercier" Cc: Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Efly Young , android-mm@google.com, yuzhao@google.com, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: memcg: Use larger chunks for proactive reclaim Message-ID: <20240131175059.GC1227330@cmpxchg.org> References: <20240131162442.3487473-1-tjmercier@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240131162442.3487473-1-tjmercier@google.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 8B440140022 X-Stat-Signature: 94ruyxfmmg7y6ec9np9aih98igjupmem X-Rspam-User: X-HE-Tag: 1706723465-452733 X-HE-Meta: U2FsdGVkX19q02ba6nxChPjN4YlZLXLx83+W9SXhhHlWHFTBfBp48QilxPwyst7TLPX8oyldw+HGB4aqYAw5Fys5TmCMMDm6Z6CobMiF80E+ISgCd9NBqtM4VjzOjVfmtHY61rsdSi95V7Jr26SJNAbzOtihITiN5I4/mO9CWi0DCGSp1e7PPjfMqDQ0Ef0aXC3quJ14GnCx3T+FjVVafJWm+2Yo2FQq2dB/w0IA+aet2V7IC/2FiQOMC9oRhQa5+LsZO9v9FZ3LB/Y+E88JOnarfCtJRGPOJg9i1x+H3vTimuqUpojXZ0TxVu3Vx4GN3juwqMI0QxxN0J7dvqOcrV3ARnjb2uFX8dPE7e40htlsrdg79erFlAcEzns37qVwyeJKVTocwe5HgP4HwO016zTB0NxLTF06jVs0y+/b8do/as+BIb4Hi7+XD+SvGzKxvoIAf/hXmbHOG7GuXx1vK6O1XoNpw0KtYevs9iL+uTzdjOKsdW8FyuTmPpEK4n8k6eurHnlStK80JEqhStU3BJc34qW+wvpV8W4tn+bgIZcJkKy3bLXsdYu6BmfHcVXfMBUFeIi6DD3zJtNk1xobTwNsQiIdWLCiBeJO/4AjUIHmK9CusOHaSuCUJM2dG0mnwXaTEDyBz4z9GfX9tswa9Yx8lukelNEU0LVA50g4cDSx5fuRIBt7Q/hy8Y2P2nOuiRG8ACsRQ+azKa9BGAqn7Rg7Edjg5YB7eDYlFtJicnbTbAZfYy935dLXAKLPfSRRiwcGSM2nb64v2mVV8C/hPZT3ZES2mVxAEN0EtPRkV/OTYQW5JbTeX1Dl2cI95GDQiIe9g4fK1YefaFRK8p0xxjucvaw+7C1t1OhK0dFLeRh4d2sPyyi6hRZ7mnEB4EhdQmWX+/bC+hAYWfMqpq6zl/6EJdpvz1ZX/whMjvxoroUj3tYMy7bFCsPwhw3bkGNRLlEYyBSQllbNSkpafv/ ixdbFjTk B9tWTBP4rUuzvWID0BmXI2/F8Xv7Vsn2aagve2tBpjIPRKEbl2O4w4M0nPvg4wCFr99NL1cuEih6YS7QIFgx3PdYyySpExpZCjvERVvOx1+GvSZE6yrTQhkh1JZ52sJqaj54cqDWeRwa6f4MnsBWh+AjUFICXbR3yoHGnKvWkfkATQZYLgnOyHzIDMJ2jJUhL7R/ow9uqKTmti7s0RalaEbXO9mSeJT+iuEUe9UHtN6JqVs7CT/2KpveRNRP/io31D17cbqy29VqYpQToD13h7sG3gnYGTxqz1SYhPBAPesd+MYTRgHvxqC9SQ1j1LKHZ7FaV6n5KuEFl5CVkMVLUIcXzrJymrlLLEpAXgWtn7mTaAYggzjLYjEpvE7WfmN5cyAhO09k29fr2x93v4N9Xaml9kwgOROJXlQrsRl55Uaw84aw= 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 Wed, Jan 31, 2024 at 04:24:41PM +0000, T.J. Mercier wrote: > Before 388536ac291 ("mm:vmscan: fix inaccurate reclaim during proactive > reclaim") we passed the number of pages for the reclaim request directly > to try_to_free_mem_cgroup_pages, which could lead to significant > overreclaim in order to achieve fairness. After 0388536ac291 the number > of pages was limited to a maxmimum of 32 (SWAP_CLUSTER_MAX) to reduce > the amount of overreclaim. However such a small chunk size caused a > regression in reclaim performance due to many more reclaim start/stop > cycles inside memory_reclaim. > > Instead of limiting reclaim chunk size to the SWAP_CLUSTER_MAX constant, > adjust the chunk size proportionally with number of pages left to > reclaim. This allows for higher reclaim efficiency with large chunk > sizes during the beginning of memory_reclaim, and reduces the amount of > potential overreclaim by using small chunk sizes as the total reclaim > amount is approached. Using 1/4 of the amount left to reclaim as the > chunk size gives a good compromise between reclaim performance and > overreclaim: > > root - full reclaim pages/sec time (sec) > pre-0388536ac291 : 68047 10.46 > post-0388536ac291 : 13742 inf > (reclaim-reclaimed)/4 : 67352 10.51 > > /uid_0 - 1G reclaim pages/sec time (sec) overreclaim (MiB) > pre-0388536ac291 : 258822 1.12 107.8 > post-0388536ac291 : 105174 2.49 3.5 > (reclaim-reclaimed)/4 : 233396 1.12 -7.4 > > /uid_0 - full reclaim pages/sec time (sec) > pre-0388536ac291 : 72334 7.09 > post-0388536ac291 : 38105 14.45 > (reclaim-reclaimed)/4 : 72914 6.96 > > Fixes: 0388536ac291 ("mm:vmscan: fix inaccurate reclaim during proactive reclaim") > Signed-off-by: T.J. Mercier > --- > mm/memcontrol.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 46d8d02114cf..d68fb89eadd2 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -6977,7 +6977,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), > + max((nr_to_reclaim - nr_reclaimed) / 4, > + (nr_to_reclaim - nr_reclaimed) % 4), I don't see why the % 4 is needed. It only kicks in when the delta drops below 4, but try_to_free_mem_cgroup_pages() already has .nr_to_reclaim = max(nr_pages, SWAP_CLUSTER_MAX), so it looks like dead code.