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 78244C47DDF for ; Tue, 30 Jan 2024 20:58:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9ABD6B0078; Tue, 30 Jan 2024 15:58:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A233B6B007B; Tue, 30 Jan 2024 15:58:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89D0D6B007E; Tue, 30 Jan 2024 15:58:28 -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 770966B0078 for ; Tue, 30 Jan 2024 15:58:28 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2304C1A0DB2 for ; Tue, 30 Jan 2024 20:58:28 +0000 (UTC) X-FDA: 81737190696.08.3CE17B1 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf12.hostedemail.com (Postfix) with ESMTP id 4C7784000B for ; Tue, 30 Jan 2024 20:58:25 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KOR0+cfG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706648305; a=rsa-sha256; cv=none; b=ppmBGgfmEsKOqz0x/m6EGEFNIIYcCDLVMDGBb9eigFyY0/7bMocHPwGxA3Igb6jP6Bc5eu U34XzIIbfvinUCpWH2Huuj437anpEegjX6t4VaXTF/boIMm5BEFHy/lFMxJ3Fgj4WKJ0Md iUAd5SR57wRDsixjJAZs94HM9Q+JAPw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=KOR0+cfG; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf12.hostedemail.com: domain of tjmercier@google.com designates 209.85.219.177 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=1706648305; 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=1cPbys/Y5hoKUbO/5yIH1p7bI18xQRJxP7D74jhJ/rQ=; b=7+6XjtZ3o1ChaDdOSzMZtF3teVZj35RfANT1fbqlaWeKSUDhlinGu66LaNX6DyR0qcb+jt b3hDYgDgz60Hyzc4yBoUply+EswBBxb42OTI5IOoLpH6bKyElCgM9BLZc6yFrIbtgXj3YF /dpOtCDzQ49wA8bfYD0GadrvBKKK7qc= Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-dc6431e6cc5so3360046276.1 for ; Tue, 30 Jan 2024 12:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706648304; x=1707253104; 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=1cPbys/Y5hoKUbO/5yIH1p7bI18xQRJxP7D74jhJ/rQ=; b=KOR0+cfGn0bJ6eLEkZz6puTRUGoEqcfmFDZxYCigFv1d9ggLVP7HmKpqZ13zZhjT7c +zfE6Ahrnu2PypPr6DoqE9BCxHJZ33I8sN/C0daGFY123dj8iBINDxcn53lFfTf6NOm6 d/AZogJrTBM2hEJZ5E40yAcAV/VrD2/Phwh8F3HQYPPU753dBHh4NpNGY20qiEbgV4Y0 MOFPkdFZbncPiId0c8ujJ8tpbvD0KaPTEW2DEWPS6Sj4eqanxiUCEeYugm8PpAJSuTT4 gdN+F0ojfWVv+tGxw9RsYft2xn/G83UHC8yQ9DL81KiG5vNWfTKJ+2u5nOmwXJw8+zEV Wzlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706648304; x=1707253104; 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=1cPbys/Y5hoKUbO/5yIH1p7bI18xQRJxP7D74jhJ/rQ=; b=KxEHzWJuXGHV621ttAglYsbhUOZhI3KRuOXKzXGJ6RKyd/Lah5+HR7mFERs7uBBwej oSQQrhfzZkK7hfqiuI0M5w+ZH3u2iWHu6rMXe6P7CjhNEkVE42A9Z4+EL/alRTqGitlC TbpIk80TGRfrpegrub4asHPSLveTgXnuUfXgZAZkPdpLL/3jm3l4R7bVIr89c1l4SeDt XJRmlBJ/7qfq7imVhHsW3Xh06p8m7mpeijUZfEd0NMae8LNinoKDrxiVmkD72ifkMOEe u7IHesARWu1/AOUDZMqaMxEzXL2MLruGnjnEEBh9ZEpB6LQff5F6FIKv6h1bZNuj82gu eMEA== X-Gm-Message-State: AOJu0Yw1SCBZqEr/JmIph3/iDiXiksseSlCR8L3kWniIY0SlnDXlhPvw M120K0RGTJ6dUWXwS9abVO3M/gmrWvQbhRiYcSaU0gEnePO63zAKV16CEUcCmqj5tyPMmPiCc8U obmNiJcrEdLMLCJzkcQE2G6+Z78aBoR18hLUm X-Google-Smtp-Source: AGHT+IE2HSc4egvJdx2fjxCwain/Mb1dWxlw/tR7nJqrykL1PcU09AhpKomms3ZlsclC9yTo3KpawTUHPHE75lC+v+o= X-Received: by 2002:a25:b206:0:b0:dc2:6496:f41d with SMTP id i6-20020a25b206000000b00dc26496f41dmr426963ybj.41.1706648304224; Tue, 30 Jan 2024 12:58:24 -0800 (PST) MIME-Version: 1.0 References: <20240121214413.833776-1-tjmercier@google.com> <20240123164819.GB1745986@cmpxchg.org> <20240126163401.GJ1567330@cmpxchg.org> In-Reply-To: From: "T.J. Mercier" Date: Tue, 30 Jan 2024 12:58:12 -0800 Message-ID: Subject: Re: [PATCH] Revert "mm:vmscan: fix inaccurate reclaim during proactive reclaim" To: Johannes Weiner Cc: Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , android-mm@google.com, yuzhao@google.com, yangyifei03@kuaishou.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-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4C7784000B X-Stat-Signature: 6aet4nimwncneh3zf5685ms46wqg5anr X-HE-Tag: 1706648305-329085 X-HE-Meta: U2FsdGVkX1+in413bjUzf5oEQ38qQWdnYBJ96AzZQfQa5L92TJI7uAw2kkGQQHG5ITLEPqjQNUu/BNowdKARtfbINLJIZzf0U3UAZg58QsAZ8Stag2LoKqyTJ17y+buk/4G0KXlJq4ugty9MqmT3d3jeSKCZyrf8LS2hDVXed6YpHwPoYMHfnkfJUT0WQ6Ep+f0vgWimXy8wOZvVIt4ViEE5jYzxxVN6jhw6UTqPR4Mj71/fhSo82wgSTWGi6VHhlkilEkiMM/iUVMOna2v9dVZlGz+BdLFApCVUZS8eqWwl4WPTCaYnX3f1ouEZNOiteMsjqcVzR0oImaFZfDciHp9lXdNm3puQ7CjDZV0c1BdFHiewrayeqfYb9ZOuGjebV0RLUnn1O519yUER3yNXohUuy9dPnnsF8KJmD9Visoqg7r4oQQ9irR2uF11Dz9YBjawxo4bvzqDKFUAm/6nQeqaOcocq/khxJui14w7sJPLy7oItGsjGU10CM5wfP64NJWfq3nGXiVHf+FzC+pBtLJGQZiuQGwkBU6NfYq7slIRnV0/nP3B3P+O91uxxV5CI1YOThiKT5u2XJerv5AmeqWNccLvzVdP44ro2MnLyOrM2cFh45JX0YwveGCTu0O7faNWacyd6Uoko6upShfBtxTSNmaXn2Jzlli6FXn/bShOEBs6pxktdM+dkLM+ZiV3zweBC4wzeUztkd0WGaWfBJWri/VpyctGB8FoLdjRmFkmjGVIVJHihlTD2zwuMOkktoDYz91D1/v21ITfOBMoJmEOgBIXrTInF3JYQKyR/u7xIvvmfy5RckI02+M7zWjhu6Dt9+EB/P3sTztQh3jVlBmjzryTCDMuxc8vvARV5cFuh2VnmF8pNwwl5IJu7H+2Nx1E0+iYaP+LVH1RwVEFTbfujAe/AanyRNMSHin98PzjaeLDmRhtehCOKQ2qWqzBaJB4CaDp8om088gS7/1+ tmVsP9Gl zAZKV7M1K3wD8SUX3zQj1oFNQgxU17bPhvL+ocxS90r9BSFpvVrGyXhhqAJiB2mf0ffJBtGuhwZ3Kyf70/DTQYlepzD0C1Lalz+Ym0MyK7/1nSUJCnhv72o2j4oez9jcXkj3k0poHFoxk223lcOEK1JPtKQXtf1/Ak4EGKnq7nAEYAOcMMu2m8ZW3zTcYq3rFfJb5/E/++cHLC28EA/hoXSgFhth665ureH++5+GVOxpt9vo1c6JIruhhbGRtjEGBYOy2HXOLWg2YX56c5vm8J+pnJWdWAdfyiJm4P2dfaYCR24k2NLS4Gw1iyw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Fri, Jan 26, 2024 at 8:41=E2=80=AFAM T.J. Mercier = wrote: > > On Fri, Jan 26, 2024 at 8:34=E2=80=AFAM Johannes Weiner wrote: > > > > On Wed, Jan 24, 2024 at 09:46:23AM -0800, T.J. Mercier wrote: > > > In the meantime, instead of a revert how about changing the batch siz= e > > > geometrically instead of the SWAP_CLUSTER_MAX constant: > > > > > > reclaimed =3D try_to_free_mem_cgroup_pages(memcg, > > > - min(nr_to_reclaim - > > > nr_reclaimed, SWAP_CLUSTER_MAX), > > > + (nr_to_reclaim - nr_reclaimed= )/2, > > > GFP_KERNEL, reclaim_options); > > > > > > I think that should address the overreclaim concern (it was mentioned > > > that the upper bound of overreclaim was 2 * request), and this should > > > also increase the reclaim rate for root reclaim with MGLRU closer to > > > what it was before. > > > > Hahaha. Would /4 work for you? > > > > I genuinely think the idea is worth a shot. /4 would give us a bit > > more margin for error, since the bailout/fairness cutoffs have changed > > back and forth over time. And it should still give you a reasonable > > convergence on MGLRU. > > > > try_to_free_reclaim_pages() already does max(nr_to_reclaim, > > SWAP_CLUSTER_MAX) which will avoid the painful final approach loops > > the integer division would produce on its own. > > > > Please add a comment mentioning the compromise between the two reclaim > > implementations though. > > I'll try it out and get back to you. :) Right, so (nr_to_reclaim - nr_reclaimed)/4 looks pretty good to me: 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 So I'll put up a new patch.