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 466E3C47DB3 for ; Wed, 31 Jan 2024 18:01:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7D628D0007; Wed, 31 Jan 2024 13:01:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C2C6D8D0003; Wed, 31 Jan 2024 13:01:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ACD9D8D0007; Wed, 31 Jan 2024 13:01:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 976C68D0003 for ; Wed, 31 Jan 2024 13:01:43 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 62C0340D3F for ; Wed, 31 Jan 2024 18:01:43 +0000 (UTC) X-FDA: 81740374086.09.E384D7F Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com [209.85.167.169]) by imf19.hostedemail.com (Postfix) with ESMTP id BB5E21A0042 for ; Wed, 31 Jan 2024 18:01:40 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="w/Pxftr9"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of tjmercier@google.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706724100; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WWmR64VE/smMIa7JDm7Z3BdAsseThN2dj0ieIZ3vXbg=; b=NRUlTQJWr0JB89n450QHOAfCDhRr84TkNfyil6VMoV/q1Y0wrCuXo01hvbih9UGOaAWzqv v4auWSBe3s5gbYM57N/dfggJGdfdSBGLcoHFyFuisyNSx9ePF5Vnt0qYq7wUF5CWGgu025 wChS6bMXhpEPZNGoJNnMoJfrZj6Dn2Q= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="w/Pxftr9"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of tjmercier@google.com designates 209.85.167.169 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706724100; a=rsa-sha256; cv=none; b=02Td3TDX4nYPAwyaO09OeP/GKYXBJUodZxcxJm10/FNbwspkSrfQCoDARzIk/R7T+aDgmX 0MZuExCi6Au24Hv6Ej190vufGJznCK7QM+3AaKLd+Kl668wIP5DcTedcDStPi79H0GWXiB TXl2R6anxHpqBbtCanJ0JXfhzOb/LlE= Received: by mail-oi1-f169.google.com with SMTP id 5614622812f47-3bbbc6b4ed1so37561b6e.2 for ; Wed, 31 Jan 2024 10:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706724100; x=1707328900; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WWmR64VE/smMIa7JDm7Z3BdAsseThN2dj0ieIZ3vXbg=; b=w/Pxftr9VONxPxJUZsTTxcjr8hNK+3Rt5NLbVnnNzJgNA35m3QUjdBC8h4f27gnRh9 bvidca0qbQLU5cfBf+4JdZWXEbqyvpYIiJF/wIe8omj2Qobw6tChY58ZilOgrEMTcHGZ y9ngQkIQO6+nOSCwqL4oXx6NnrGUTJUr9qjj8XVGro9K8BA2YjQ2dfEBQNvj8YT3Rt4/ aEW309eMG5irjRvFfH8wi9LzlUZJD+DnCnvWRKozn8L7DJnb5xBta7XNUOZBvQi1BGfS g8PRPxZcISTS7VyOQRblzygP3K9KaZckxV3fNOZcV8Y7Pjtsmpu1xD9/O6YFRTqJgd4h Fj0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706724100; x=1707328900; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WWmR64VE/smMIa7JDm7Z3BdAsseThN2dj0ieIZ3vXbg=; b=WpriVwfPy/Xkb0OqQKfyvvB076m4HgV3PWJ4BabWE1Db6k6GxYUtxm54vFXqnb4drh /YIrTh6qp9EtO5Ot10DX1wICPxFXyGVZdDTJ2h3RK9t7phphhICjPbSsPYTj99Ni59IB vt4Cadt9VlTnroEXCN3J29xapH9wt3wjoJwqLIJzWM16uAXzgY1OxRCDL1c/NKL/0GCD agdM+fV/vZEiDWBslMh1dyvc/vjqkskWv9dG4gJXo6FzDrqS1FjvGn99zcNUyf7y99qt X6kBV0QMGYFv0G08S2rq+z9Rw7HNEV82ohT4wfs5UwgqKNlLuQpm7ZYQnfJ1tJJDKf5h EVSA== X-Gm-Message-State: AOJu0YwVaoQdR5KRWLb6jHXAibTVZc+Tw5f3TRD6WlCdYpUXwRIMYYPx jcAdVw4eqylRw/td6eOpRTKwQYDGkNPiNjw0hm7H1CfYmVP+c66VFFg3Z6E+xzcMrBQCzcYORNo eJU5oFyRQJT5j9XzmgSktuPFLJNlNipuGlScQ X-Google-Smtp-Source: AGHT+IGtHgEj8tA6DKcs4XLUjgq1qppyqHJDhhSHFflfn5xowdZDCma3tgxFRdeRXZw280nYsPg3hG3q94c3E1S24sU= X-Received: by 2002:a54:4187:0:b0:3be:c69f:ec08 with SMTP id 7-20020a544187000000b003bec69fec08mr1500145oiy.59.1706724099702; Wed, 31 Jan 2024 10:01:39 -0800 (PST) MIME-Version: 1.0 References: <20240131162442.3487473-1-tjmercier@google.com> <20240131175059.GC1227330@cmpxchg.org> In-Reply-To: <20240131175059.GC1227330@cmpxchg.org> From: "T.J. Mercier" Date: Wed, 31 Jan 2024 10:01:27 -0800 Message-ID: Subject: Re: [PATCH] mm: memcg: Use larger chunks for proactive reclaim To: Johannes Weiner 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: yqfcddy83ih9y51a86317kkq97394kq3 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: BB5E21A0042 X-HE-Tag: 1706724100-95378 X-HE-Meta: U2FsdGVkX1+SE3ygJY2yWktRyzzNZdKRWUOCS9EVIoz35eF1f3dd/w14VNK5Ayr7i5D3OLCE4elm43cMOJQ6NDdBnKJKDSBrAXGBB1ZCH/53S57d9QC3KrgoFyy5MKC9dHcCsdyVlPWwBIlsat0Q09i6uYxVoWsGmKho+Lujf3osw3t6gUfoMx30UcIuTgslyOkuz+Vg/ZWW5Wck/xOKE2dlQ1N2nTMf6i4Z/BVtMGvpVk1eCdQccYamGXHCLPwrF3mu5ZkhQ8AfAdyWcGv7yRj1aP5N7J1w2307bGimhjUsRDItv3DIlLWN0qtNXAuKLMtXiea3pvjCwR5vD6JbFOgPU1cGOA7t6PWVkro82xvxwBlibF9lHA7a/EkK6GUXUM946Mvbal/Qn3GMCnmoayzbPUVg96M09f7uNcF/HdSz81esc3frVm8Tf/ii/VXQr0PpPOT4l6KaFLFXBOs3kfbWujKu6rg9VyGZbGPgSh2Qc9yBZyAgLdb1aBLYvga8Zx/aJKHdwokw5EJSuujlbi8stD7cXIgtVoaawkcibspWRfz5zhCug6sTzcZ14qvpqCLA87+YoWNikZdc+Sw8higBtqH/SxQNJe0JUPR0NZeRNZUgzVh/7aUv7j0blumAaHYxq4jA/QcFBGO9WF6+wZbebJklgxBNWiKIOoGNWgv3djs/0sXHxavJDikQnfxNAoMUqKIwkv0P2Evy/WAr0RIBe+spxdtT12xHc/5hOXkC7iZOe6Yw1Lu6j/JyghmmFRx6+uIQVlgulfF+iYhHRNy8TfTFXmj/1J+EK4hCL5yOdFogCzMSa2gDyWrmD+oD3owPBiv23fu5x1Wvb8O8cHDNUdG453OGdwwepfT5phv1H79ig9dgdDrfvBfC2U71vSke/jyn1xc0mDDR7TF+TSQ7xPVlTBOlWkzXc5MNt1bWSqg5d/iBvzMjJAlzjRiPkHqFaHUJJyRtG/Oj7B/ TOHg3Rj9 t27gL 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 9:51=E2=80=AFAM Johannes Weiner wrote: > > 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 directl= y > > 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 proactiv= e 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 =3D 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 =3D max(nr_pages, SWAP_CLUSTER_MAX), > > so it looks like dead code. That right, it's only there for when the integer division reaches zero. I didn't want to assume anything about the implementation of try_to_free_mem_cgroup_pages, but I can just remove it entirely if you'd like.