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 E0C19C47258 for ; Wed, 31 Jan 2024 20:13:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B2578D0002; Wed, 31 Jan 2024 15:13:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 362728D0001; Wed, 31 Jan 2024 15:13:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 202DA8D0002; Wed, 31 Jan 2024 15:13:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 0DF018D0001 for ; Wed, 31 Jan 2024 15:13:27 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 16C331C16FC for ; Wed, 31 Jan 2024 20:13:04 +0000 (UTC) X-FDA: 81740705088.02.BE64C96 Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) by imf03.hostedemail.com (Postfix) with ESMTP id DDDC020005 for ; Wed, 31 Jan 2024 20:13:01 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=2QNS77Rg; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706731982; 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=DpN7tAlSPEJaxHsz1Fwia1gS3Vdtxd9q2yNC5JJCopI=; b=OlgJhcdvJPb2sGZ4XCFftMNiKYMbhSMV1o/QCHeTXncrXcHawQwyu3/253gR7OGQQPDWLJ tlN4DqHurmZgZhRQjlGqjF6r1rIlxeeNGslAc2Q5k/mgyM/I4GN4ZF4mSjOAspkmCp5R4W a0RMxt4OdYSHB3D68JPXv6XX+F+f4Ew= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706731982; a=rsa-sha256; cv=none; b=XmfyHlhgY1BjpLMkQMqyUfGHHhR8OwBn4FY578T1DP6s8iYzlLueFlrXK5J2He/2aVOdqD n+qOO4amkkNSsV4Y5aah/Q77k2H+mCzk/l2s/j3VsCu9HTq1uIEYnJ/IYKQkUD24bZdeiG 2LYYlqavKokV0Y67fBM6VydtjTPJV1I= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=2QNS77Rg; spf=pass (imf03.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.52 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-204f50f305cso85394fac.3 for ; Wed, 31 Jan 2024 12:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1706731981; x=1707336781; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=DpN7tAlSPEJaxHsz1Fwia1gS3Vdtxd9q2yNC5JJCopI=; b=2QNS77RgIHpEhfbZaZ77YwKEaUknBTzO1UoWB8V5qng5BbTYvORTGs5DYKdVT72+J5 XuWCE8oYIfcyN4oODDCsBEwZUxGp+YhaB31+m6fUSzR77GiXnGeYEhUIf8Z43ZhYBFex AaLEcSr0OaxKvMGmyyvylpmcJa0IofVQB1C/elMCUvrMVyCG3PZh/y6I3PpKr2DKpEgf MeTZ1EbFbc244hC6t1onHCqAu1iLgzVtt3D8RsY2yWeeZq2fpJNiJmKnp+fbk7STfJG2 3tDEO6MG86k+zhFNcrZLpwNYqDCQRJ5N9N5NM6ctnUDwTmGUFBUgon4LD81dqsl/uabE 11rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706731981; x=1707336781; h=in-reply-to:content-transfer-encoding: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=DpN7tAlSPEJaxHsz1Fwia1gS3Vdtxd9q2yNC5JJCopI=; b=wOio9hCuDGO+3LKKlc32KcLRw8puae2mdic9vLa3r/uNcw+Q0AkX7kveJdKGDfpfrX 7LRZCwSk8Ut8yroq6+rwVweelwHXBvCtIft0BM/bCPkknpKCT99bJ2kTJuGwuxAmAGuL uAXRM6xeM6r3pQRydAfOosl2XYRgBs7+xhLXcswCTeWDOUb3uKEEF7SUXBohg+qhcNM8 J0DGUA1uzXd0Bb+yIEkjR94KCYu6JCL0j9wFJAjEVS1IoRDRtYUHN5Z+4D0oNZPJt+an ZOB5j9lHsl+FC8wSWbPNuiHAtIC2fUXwnOlb+69nVbWXh6mFNpcf019g6mpHIOwEhv0A rRKQ== X-Gm-Message-State: AOJu0YwuP72tNv6ViEo3wWp89U+zb3S7+eUrS0nsnGbZoiORDRUGv9Hs 54LtPBgtJL2kZFWauKZYWN6Ev1ZPugdGVDEIxWDKcl3ZPOO3hTdxaFDPA5J6N/Y= X-Google-Smtp-Source: AGHT+IG597JmUsw0p9ugvB+ssXuN78/0ZfDYT2KT1oI/JaIHUBM0vXaUMn1SZIeIHb3DYXS6CLUxtw== X-Received: by 2002:a05:6870:15c7:b0:218:889f:46fc with SMTP id k7-20020a05687015c700b00218889f46fcmr2667215oad.30.1706731980877; Wed, 31 Jan 2024 12:13:00 -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 nf6-20020a0562143b8600b006869485d9eesm5789124qvb.82.2024.01.31.12.13.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Jan 2024 12:13:00 -0800 (PST) Date: Wed, 31 Jan 2024 15:12:56 -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: <20240131201256.GD1227330@cmpxchg.org> References: <20240131162442.3487473-1-tjmercier@google.com> <20240131175059.GC1227330@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: mrtok4wqp3poqdxfmjbfeoqbd5wdnxjr X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: DDDC020005 X-Rspam-User: X-HE-Tag: 1706731981-537167 X-HE-Meta: U2FsdGVkX18ipZuY7dVPkms9Ohz4FmLRmCPT1N22hXprVLAqMMu5B0vk7wDJiBs9qnbgcA0oKgOfQdRNRr/76cSFex96ezAcS/0octBcrsZOIF9JQdWXmHKE1KSFng7XI+WKVnLFtgWU9KC1wmZNqTuQuyQ34Lhi0Sttgztf07N1/jsxYKOXgggOWi/CL72JRCXx9iugFsXJJSH+0C4+NugIMMjQuY982QBh71tB3uG5ZF8ARwsmdnqgdXYUNq/lehhHVz7sB5daookxCIvnzCZ3ui5KzMMydhvwB9YFYILZ+dMb3thaUPARyb4Q3xCa1DG/wyRz1Q+PfiQYaWG8kkDuv9MOuz8xEwBwRMFBOnNdUuG60bhE9ATASMXzecpSPVmwloSpOcLDzT2BPk1heKKKAUrONjo0EN691xYSf/xWN+JPJJOipavD7WZJTpLMersF5PdWH+swEtpF3r/RBmJgKdSE0XxcJJSKXN7guEPFhMnwLOlb7p5Jl5DRezjBxLsr9cqWFFUFoNCOY9DjHwLHdLJXRwgVNTQJ6D9gnH8WmXJAFLb0+83eh9PiqI3zRPi4EKrQzlEgJYrPqCNrK7N0vCjPT/FcutFDhqvcGSyZMgps3t+4dOD+f9oXlmoCrJSYjAVEAzDB53lScVkzGrZ5qnEFTY0DyRt5IgQuCUpgD42a2HoLO4fenT1DDARMwGY41HACAg7qzAvTxhDAR95AnEW8jyIOSdYwNY8RDKNChhLtXUejdXPb29tvuTS9JWlnWijis377M6ZKrww82nJTILgKAaM/dEVDClICZoBMUD/9ImzWCwb1KncEmPVXeHVX2ghpVlBI7zY/yOMVrAHV+Q6PS3efQu5vrVJ8TWv1z3rSgAwOKaPuf6qOZI5J/YQkiPxszNbIL3jmUHg7F+IYWEkAibEgbHFsmq4LMAJ89VqSHS7JBxsurg931Vr4EukKCYDfpfFfQ5zoO8r opMKJ0vl yrka1GM6IhJVqUPGe6pk3SYkhzm01uPI9K0lSFm93XQxwvRJJh76058890EeNUxVbgAutt2soB/jOmt4fajsjXmxMObxMjPNO1iIeYHHarJ0kiTYEgEMA20D4oR1GMFm0HKz5pGLgjgoY0GJov77+V90uHfd1btDQhodZ3iAzSaH6GrpHxnb5W5QTvdVIfy5iseaW2gKHQUkhGeAcDDdhLhlMs0d5PVGCYDetX97eZWt9F5BOenegNKKYyzjQgGuE1YAfy1Q/gJdC3QwLrw8NwcINIjBZgPEIgrbNMJndZbcJ8X0mrv/UUa2Zg5XLwUvk7APozRiAfbp2hYoj8+k84Ph5Q9+CeKKbWbKy7cfefTyYhPgXRs0GbGR3MQuchNjNV3Y3cVAGrQvSyimoZGAbQ8I2Nv/fOaewP6iAPrKXVMX87p/oMiUJ70hu5ZHAlYZiD5xzLKS8wwhCD5qLpEzSZu4VwYUVH1+OGtTwkNUzGkxWQ9JpwsdqvD1BEmCC7hdT22uy 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 10:01:27AM -0800, T.J. Mercier wrote: > On Wed, Jan 31, 2024 at 9:51 AM 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 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. > > 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. What do others think? We rely on the rounding up in a few other places and it's been doing that for a decade. Maybe lampshade it for the benefit of the reader: /* Will converge on zero, but reclaim enforces a minimum */ but otherwise there is IMO no need to have defensive extra code.