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 4C426C02188 for ; Mon, 27 Jan 2025 13:31:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3C2F280159; Mon, 27 Jan 2025 08:31:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EBD2280157; Mon, 27 Jan 2025 08:31:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DA58280159; Mon, 27 Jan 2025 08:31:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6BDEC280157 for ; Mon, 27 Jan 2025 08:31:15 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2A5C7140113 for ; Mon, 27 Jan 2025 13:31:15 +0000 (UTC) X-FDA: 83053318110.19.9194675 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf24.hostedemail.com (Postfix) with ESMTP id 3B9B5180008 for ; Mon, 27 Jan 2025 13:31:13 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Ta5fZT8u; spf=pass (imf24.hostedemail.com: domain of mclapinski@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=mclapinski@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=1737984673; 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=vpoVm+VHMlWt5wBSbIJOx2BT8YYSYfXPnLC//lbsN8Q=; b=fdVFn6nGTEj9bExijT/T71CYI7wR+Putfo3eYdcIyAQCWrt1DXvf4uI7R2OnyTZ5bEVESe WTzyHXzHdwPkhIi5toRMJTOTxjpoLmjO0kb0e1Gk5R5ohPQt6KxuS9w/Gj1niVPewaHyFz hKy51A7r+dTAzyB4Lk2jW1xYG0cc0yQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Ta5fZT8u; spf=pass (imf24.hostedemail.com: domain of mclapinski@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=mclapinski@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737984673; a=rsa-sha256; cv=none; b=eddcbLw0dDwGKZxa0OQjNWCpcLfyYyCgoiUMrArBHVm/FUas2pYRtlGBwW0QxqsttaI3VQ TZ4dTcEHIyUe7A1OD0xWfKbs0B7dbDFJ2KcuyqsQp0DiYSQgc7Yxi3pKGUY9b8l/lKDORZ uUevmxabjtoyUBT4vsaHSspnoZbVQiQ= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4679b5c66d0so406921cf.1 for ; Mon, 27 Jan 2025 05:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737984672; x=1738589472; 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=vpoVm+VHMlWt5wBSbIJOx2BT8YYSYfXPnLC//lbsN8Q=; b=Ta5fZT8u3H00RVOaHCDctsEENmQCECMPduaM3dhcJpfsExYUN6Dzvvpu5HHmLklj6/ pSymcup9LQR2r8Ml8zKA1wUHDVe5lW2zHlzhpgG+VUC8/QJJASsH+s/PZYq7D9BnJhHY gpd8U3uL9AnOVZtb/qtJgINbNDP6Dxc5dHeIagRsTADtmv0hf41Sa3PZFdXeruiQ3L6v cj/ksng6mDKULscS6LZsUO5gq6RQRyEs/x4Ab9JHZ4yWcoT02SlmIsNQZuF2MRAZ6Fwa sB+kClb0SToMT8PiBbPlF8sVWkXJ9V89FD+rp2G4EbduVBDsm0actI98pL1LnT0imYOI D94Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737984672; x=1738589472; 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=vpoVm+VHMlWt5wBSbIJOx2BT8YYSYfXPnLC//lbsN8Q=; b=KfVIT491He5cCh6TqW14hcDAAdqe2p7C8eFWzv6UNkPSxS8lnYAlGCskVvzXPckfxf AsMOIALf40ueeIivHxUrr2Hza2PC5WvSkfPCY5cWnG8jq/NFTxtK+TWGXwe3eUDM3Zhb pGZypK5u4lc3Jl/KjNGjd9m4HRVrg5IngxzUL19EQhU7SZgVZSY4WWHAqqByCBdoFBeq mouzeMTqYQxKVOfeFPKNtqmUlH1dJPLFRNv1qfPRC/MeXsIyu+ClLXM4dgpmRWvhcVhg K7tA3DQPu9ZprYj9yYHaneH4y5t/RTYuC7AI4mpK1GIWb+4AIwYRFN97FA3evFiBQUBK Nz1w== X-Forwarded-Encrypted: i=1; AJvYcCUMm/SV8jOTMcMyznG22BSVu6trTSujFQCcLn/k0ykvCj95n1UrzX8s2PkPDlQ2lv3fl66CDtokDw==@kvack.org X-Gm-Message-State: AOJu0Yzxko+3kZNGmxoc59FLmbjnNlxwhtWGxq2C633pNm/96VvrbT2g WmXTQaR01oozGOua2bvjTYXKpoDMrzCbhQoa6K/cDLERU7WV0kyTt5KVsXkz59e2iPuYCp1v8fz bMdSONj02J+9lgXeCMrtssvi3tPV/WRPM1C64I4526jX6ph0JSA== X-Gm-Gg: ASbGncuboaD/PTalkgFLG6TRMHvJwqlkn/Ka6hVyusR7owoGh1eH3+AgaTA4GnPg9dR LShHUxnDEoiNgJtbK6OJP4GCULhz8uW2wzn/QZE6NSO9acuJnPy5tyarPksRl9OYuX9OX1ufA1R NKpqyHHjLwBVWEBw== X-Google-Smtp-Source: AGHT+IGHCw8xEhNRkAoGlLiEGS79nsxgUeVbqyFNtRvsaKEaf3NnuWNsOCZDP6EACqU4LtUZj3Aw2+lxHFmlGlLRPjg= X-Received: by 2002:a05:622a:1c11:b0:467:8416:d99e with SMTP id d75a77b69052e-46e7798f8c3mr6470181cf.21.1737984672032; Mon, 27 Jan 2025 05:31:12 -0800 (PST) MIME-Version: 1.0 References: <20250124182140.2243862-1-mclapinski@google.com> <20250124182140.2243862-2-mclapinski@google.com> In-Reply-To: From: =?UTF-8?B?TWljaGHFgiBDxYJhcGnFhHNraQ==?= Date: Mon, 27 Jan 2025 14:31:00 +0100 X-Gm-Features: AWEUYZl0KgheC7W5kg23qDtbFAmY0KcXvqfyTKSTgOXcyiKyhrHxlsm6J_v-Av8 Message-ID: Subject: Re: [PATCH 1/2] mm/compaction: remove low watermark cap for proactive compaction To: Vlastimil Babka Cc: Andrew Morton , Nitin Gupta , Pasha Tatashin , 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: 3B9B5180008 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rcungsiqj1e5fhgt8hk4qxh8to6bd9sp X-HE-Tag: 1737984673-233991 X-HE-Meta: U2FsdGVkX1+1xBC4vaLtmwL5IRziCToY2ghjHsU/dCDvrtkwukkEehlWoKwSLQR2OsHM0Df6cI9NJACOHs/mmmaKlPOwgHxocog+CyORmQGurLlbwGCGPUBQe/vQtcqInwTs5oGkNyw5p2Knb2ZGdvg+mPA5Tz2V8O9i990p603GeiG6clUgmsWS77tFDKNJrOEXWP2Kfm2VpzPox2ops/4kCQMVg3P3u1k3GeVJcj8YZpTZB3u/W6t4qi3SBAkvRPJooLlDzCvzJq4zJNSQYeJq3lWJMCJRrSwjLyCoBes7Y2ydT7nL+GX2JHswWHxAn5hmhJO49/2hM7Ev99YYwgAnPtoVDgO+qlj0AgN3yGR8McnJpb7H+zHCyB7swvIDvyDpomNsGkO/7HVjxDRmyxFbSnyxB4Yd8q0Mc1c1wMLgpulgd5lq9qPzqNbHTtbeEpOomPWUUPXVjCP3v6L6gg1PgZns82H5GZ9lUcmLI1aPSM156JRh9oz0tTIscQr+wIynbFsy0TNnyYYvzd1KhGkJePlzncN+VpNi7rNABjXxUTSRNCxeaJYdPkz/Crweyk2XssBm/tujBXupzKnRf3TZ/skw8lG23Xk6xUOCZf1QnaD0wmXtPUyCGeSa0wX1q/OWSXOmg8Ht8/6PIfJ+dNWIC43JMxpqz7pyCL0TwQkwVhI6IyzIzFzVF0DoqP1O5zq0pOsw6Ws1lxJOV7w5gcLgtU5TCHAa1cSzl6oCafhG722ovLzX7Q65OpiNOzZU9krkvKluuwhXSt/HGWiebT3L5LoyN+0XAdf1+RU1w1XMn5JLCjbJOs71wdQ+6EFNDSIBU8Ov+y4S+qH87wwPEQYYEFzcIAPwqcVyMfRHwiw23Dfm7KgEFB5jjLiGjU6jGI2hHNmOJX/x8eEZGbqdX0MQuWt+jWgbyvzb5tucq804XtyGqRWuzj1/rx+BGONtwGP94JX2iq9Uc7btRMO bhRFWXxA wQ4dx+QzqAOGFzJsdAE4UWfFmv5Qknyvj4TclJJt6UwCm/ZIyQIl5T+bmOe9b/UVSOqcJs6uk3xBCkyWHxLVD0X5DoiLkHLo6GGy2jHqFJCt1dgKwrVGv0TCHkjMrDnh/JmGuiDRe8DiY/MN0Tm0Ca7Z5csTBB02Eis8NMw+9HqVPlPUFSyrMMZFhajbPulNwzd7c49hiK1G2IMkf1aw1B1rKGeuVyjQULpK6iANIk+fWFn7HCvYkxyG9B7F/4ikl1JVNZzQyesrOJczazoSTw8K81bPjiWEXF1EX 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 Mon, Jan 27, 2025 at 11:38=E2=80=AFAM Vlastimil Babka w= rote: > > On 1/24/25 19:21, Michal Clapinski wrote: > > Previously a min cap of 5 has been set in the commit introducing > > proactive compaction. This was to make sure users don't hurt themselves > > by setting the proactiveness to 100 and making their system > > unresponsive. But the compaction mechanism has a backoff mechanism that > > will sleep for 30s if no progress is made, so I don't see a significant > > risk here. My system (20GB of memory) has been perfectly fine with > > proactiveness set to 100 and leeway set to 0. > What if you don't set the leeway to 0? When the fragmentation score (lower is better) gets larger than the high watermark, proactive compaction kicks in. Compaction stops when the score goes below the low watermark (or no progress is made and backoff kicks in). Leeway is the difference between low and high watermarks. So the bigger the leeway, the longer we have to wait for proactive compaction to kick in. Memory usage on the host would also look more like a sawtooth wave (slowly creeping up then sharp drop). I set the leeway to 0 in this example because that's the most aggressive configuration. My system can't reach a fragmentation score of 0, so it tries to do compaction as often as possible. > In other words, should we keep the cap in some sense but make it depend o= n the leeway? I could do something like wmark_low =3D max(100U - sysctl_compaction_proactiveness, min(sysctl_compaction_proactiveness_leeway, 5U)); and it would have the benefit of not changing the behavior of proactive compaction for current users. However, it would make it impossible to have a small low watermark with the default leeway. That's okay in my case but do we want to create those restrictions for the future users? > > > > Signed-off-by: Michal Clapinski > > --- > > mm/compaction.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/compaction.c b/mm/compaction.c > > index a2b16b08cbbff..29524242a16ef 100644 > > --- a/mm/compaction.c > > +++ b/mm/compaction.c > > @@ -2253,7 +2253,7 @@ static unsigned int fragmentation_score_wmark(boo= l low) > > * activity in case a user sets the proactiveness tunable > > * close to 100 (maximum). > > */ > > - wmark_low =3D max(100U - sysctl_compaction_proactiveness, 5U); > > + wmark_low =3D 100U - sysctl_compaction_proactiveness; > > return low ? wmark_low : min(wmark_low + 10, 100U); > > } > > >