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 B671EC48286 for ; Thu, 1 Feb 2024 18:10:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3274E6B008C; Thu, 1 Feb 2024 13:10:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D6C26B0092; Thu, 1 Feb 2024 13:10:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C5F16B0093; Thu, 1 Feb 2024 13:10:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0D69E6B008C for ; Thu, 1 Feb 2024 13:10:44 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C981340DF2 for ; Thu, 1 Feb 2024 18:10:43 +0000 (UTC) X-FDA: 81744025566.09.1BDB33E Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 21EB410000F for ; Thu, 1 Feb 2024 18:10:40 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="wyJ6dC/N"; spf=pass (imf05.hostedemail.com: domain of tjmercier@google.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=tjmercier@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706811041; 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=yHfuYMEKwOkGfq9jIdDUbSlih9i80eEwJ6EkAPpJJng=; b=dM8t6aU6R/WgD+WH1NrnBqT7ST+ywsnGWkS2Rnuiv1ljlITCi5ErMyeo4hXoPYE7Oe+xW5 Xam+S14h80i0WN0rzR76f9r0XdscRLywCehZ02xDVML2B27b44g/nC+aTywUshQo2bG1jz ii/iRaGPGTH4cXinRn++/EalSZs84vo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706811041; a=rsa-sha256; cv=none; b=eL+xAJSrWzee/7UnRH0BBy26R8PqVi1ktfhTgYa5WxnJls97QmX6Dgd7Cs4FwIdpc1Ymsu j4JF3GS6iTxly7uRf+dbsz/FrZo0gtQ7o9D0CUllx3rwV5kytFwaijeNJqyk4FNF/OEFGr r8QUGUSGEH8AzN26udf9UHOThz95qbA= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="wyJ6dC/N"; spf=pass (imf05.hostedemail.com: domain of tjmercier@google.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=tjmercier@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-6040d9e52b9so12713957b3.0 for ; Thu, 01 Feb 2024 10:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706811040; x=1707415840; 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=yHfuYMEKwOkGfq9jIdDUbSlih9i80eEwJ6EkAPpJJng=; b=wyJ6dC/N2F75rn284STZ4bHD3rMqA6g4cmjK8wo7mycw2muawvztZ49+I6Y6xjx6SG osz7vHP/emvcIPCkqnQxQJC/i9NKpvvXLEpGXJopK156E+RLhGF2Btxqy1gYwovCXmi8 ogsFmdVJBQHq+ke7ckvgdKT7Q5odaWHFJmyFdC3JKmXRX81fonZiHjMn9spyssR8DVk7 1ZW8K8+cqDRG47Z5POslSL5Aplv7b1Jfk4mi68pPPKhqG7pJkaKyvVg6LcLEtSSFjxoI c6I/8NBgPkOl/kdE1ZVx9hf5tFeCyv3WvtPyD68Gielwp8nFaFTSsGrF3t+2hE7DpEZN J4Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706811040; x=1707415840; 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=yHfuYMEKwOkGfq9jIdDUbSlih9i80eEwJ6EkAPpJJng=; b=mwR60n+WAy6PlvcgRI1oxm5JYeCfSKb1QHxThGMsF8ugOHmJJhUUz6VTdBRjfwPGpq jCDCFi7MRD1uQVP1bCkRhk0ffFDeCtRqOyK44+FJUKYvgwBY7dD9gjtF6SYRfX0YW8Wg PW+pOh6PeuaXoI871hkZHGCLc7kcQV8r9y3dQoR/upyQj5n5Od8y0gqxVe6gGX7VwJkY wd3AD6jSeWFU6vQjQesnrH9Q+cwcFDgRoNveVtzf5wnYjPq2tGe0Iq0rzG+dwIB93ciI dDBbSy7RB1wMiSUX5W8kzouU3GF926Jh6yZ/gXbtNy3LYCJcFdfWATQuoPmeobEAg9vZ L2DQ== X-Gm-Message-State: AOJu0YwXe6OUkW3sWZVenP3PH0E3G/8XBLtgMcgCfLT/2+DrAA7HT3C4 dNEv2ZbToX2fPWVbnyH75qzm2P+JcI4g2Ms/tQo1Um31i8F/LZUpNi0FKNF2tRUklpxRRRg23fm UACX9cQxTNIfNrKqjuaUO9QLyCDWvP1IshWBF X-Google-Smtp-Source: AGHT+IFX6go0V30fwrlIueitJQAg1llY0QsQgiGHGUNldgZN6DNqY5vqrIPusWJFHRdFdDUbuQfm/f6tTKwgOgZguqU= X-Received: by 2002:a25:aa14:0:b0:dbe:974:fb85 with SMTP id s20-20020a25aa14000000b00dbe0974fb85mr6028810ybi.22.1706811039987; Thu, 01 Feb 2024 10:10:39 -0800 (PST) MIME-Version: 1.0 References: <20240131162442.3487473-1-tjmercier@google.com> <20240201153428.GA307226@cmpxchg.org> In-Reply-To: <20240201153428.GA307226@cmpxchg.org> From: "T.J. Mercier" Date: Thu, 1 Feb 2024 10:10:28 -0800 Message-ID: Subject: Re: [PATCH] mm: memcg: Use larger chunks for proactive reclaim To: Johannes Weiner Cc: =?UTF-8?Q?Michal_Koutn=C3=BD?= , 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-Rspamd-Queue-Id: 21EB410000F X-Rspam-User: X-Stat-Signature: ogzxf87ifqta8orw1mjts3n41mew959s X-Rspamd-Server: rspam03 X-HE-Tag: 1706811040-297972 X-HE-Meta: U2FsdGVkX19sZM8cXmqwyKc5wYTekV/Q50S1lWSpJ/R6AMdZw4argbWJ8FF6qe51keUffP/Rg2dBkhdnaLTpCwCFlgYcMZhIhX1axTXXQAPzr2r7gYbHNQ/1IM5XGXtP0zfbdETcm259w7DdmZ4xAkKIxKLXRCuNYXbBOV3jmTI1A4/kab0KCGnscoWF88edr+O51z8Swdl11GjADd9GE6xDtcf+vF3Hd4lXi53akW1b16PaqhtupHRrOGhrFQ3QicpXZrTRs6pxI++3hVYP04XxuAIRvXEX5yJJudNAFVSiZmog4MbABjRA6aQ8DRyakerWs/skg9USOexk9uIXwN/Pc9NPc09fHuNreIDAj27zkJvECydxYh9GWxtVVefEpKIJqGySEmabM/E3hTliEBHd4apd7F5n7Fiy7nM/w6VNX+FvZQhnV+DXxpf9TnxQ7Kr0mabDO0jgIrxdQDmOQVPTLpmtaanVe+sBqOD+DaSD+F2zlEpNoRqTrrFcNfEf/9Kp0wg/tC/EOFjpsZABM06D+FSoH0ieswBOlwW2jBzf4H/nJls0DwmyyZvIOska4cbxCNg+pJcaCPjJw37uv2vLhN6a1d2BxHK2k7ycAES7RXRLc7vFB4H1XHJnKdTuxbMIzNUtUVeWOW+4l3+nTzynJl4gCP2e2V150etQGIpnZM0H3d45pCQVfAmCFSF0exSvYVSIRSWSt3rj9lu9tQqetF+nJAdHnLQNrMUmaIAdtzK468lKL0B0k8zkeQ2YnHZIPVkZr1sXQUpa0BqRiVFDE7iop3u4MMe1lYJIduNaJ3CrPUPr+aQwdXgurZjIDacIN1IveXC4rcop3bv8/njl7hCK0gjgCwv52EefYukPxF0G01FZZ/6ULpuIfz0xbB+aLOjIuCntGvQiXvAJJjdrv+PPOH0OO3bFlwwE+I8OQjnTpuhSKli92GGzCGYThPaAAxyoKK7Ymo8swOr vOcSwa5y eB2sHNAA+IXvV4vJlhjcC2onbirnH+w+hGyLB5EKUohbrSMoFFnuIFfgpFJfmNwpGe5OnF+lNX0D0W0cPI04/QakFpkXvuiuMY+C4GjMKIZ700mYw/0IcIPxl9v1Btsf8hBfwLGTKYN5V7nZ+1CfHjcULvT24uztyRnFaD5qaCOS0Jr9Souc4CBBAtfsnFwph3zU2nZKEBuL9XGbakKLhMesQbXv8bRPC63uetRNbPoaAW5/ETgnQ0wn1SbOgqSa31uYgrfidX8CrZ1mWT+eVhmJLpNa8Es559ZfHM0uJ5d9IbUbr/ItBU0qKjw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, 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 Thu, Feb 1, 2024 at 7:34=E2=80=AFAM Johannes Weiner = wrote: > > On Thu, Feb 01, 2024 at 02:57:22PM +0100, Michal Koutn=C3=BD wrote: > > Hello. > > > > On Wed, Jan 31, 2024 at 04:24:41PM +0000, "T.J. Mercier" wrote: > > > 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), > > > > The 1/4 factor looks like magic. > > It's just cutting the work into quarters to balance throughput with > goal accuracy. It's no more or less magic than DEF_PRIORITY being 12, > or SWAP_CLUSTER_MAX being 32. Using SWAP_CLUSTER_MAX is sort of like having a really large divisor instead of 4 (or 1 like before). I recorded the average number of iterations required to complete the 1G reclaim for the measurements I took and it looks like this: pre-0388536ac291 : 1 post-0388536ac291 : 1814 (reclaim-reclaimed)/4: 17 Given the results with /4, I don't think the perf we get here is particularly sensitive to the number we choose, but it's definitely a tradeoff. > > Also IMO importantly, when nr_to_reclaim - nr_reclaimed is less than 8, > > the formula gives arbitrary (unrelated to delta's magnitude) values. > > try_to_free_mem_cgroup_pages() rounds up to SWAP_CLUSTER_MAX. So the > error margin is much higher at the smaller end of requests anyway. > But practically speaking, users care much less if you reclaim 32 pages > when 16 were requested than if you reclaim 2G when 1G was requested. I like Johannes's suggestion of just a comment instead of the mod op. It's easier to read, slightly less generated code, and even if we didn't have the .nr_to_reclaim =3D max(nr_pages, SWAP_CLUSTER_MAX) in try_to_free_mem_cgroup_pages, memory_reclaim would still get very close to the target before running out of nr_retries.