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 60F48C282DE for ; Thu, 13 Mar 2025 08:57:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B460280002; Thu, 13 Mar 2025 04:57:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9622C280001; Thu, 13 Mar 2025 04:57:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 82A15280002; Thu, 13 Mar 2025 04:57:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 65265280001 for ; Thu, 13 Mar 2025 04:57:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 47297BA69E for ; Thu, 13 Mar 2025 08:57:51 +0000 (UTC) X-FDA: 83215925142.28.06F74BF Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf14.hostedemail.com (Postfix) with ESMTP id 60A07100008 for ; Thu, 13 Mar 2025 08:57:48 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Galj0vEa; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf14.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741856269; 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=oNVte8lvt8b44yuQA7mpFTfd90aDPPxxo5o7QBnVwxo=; b=B27BNpeeCYqPfA/buptWX4eAvLGR1OioYvMbXQ4F+F7RO/6IZGEJZWgGKZMPsWMSyhyKQq SPBIfLaMVcv9gNs6FmV2R4l4GXiKwYEmpOwsbqZjlg3C18BExecVB5bsUXC3wj4QzchHqj EBe4bzW1slbSK1eV4Vi+Trwa7Qssym4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741856269; a=rsa-sha256; cv=none; b=W8T4JzrBq1T0V/BU2f1yWVdVBYrVQt8Kk6KAgWPTzXJBjytpv4cIG5ga9WHbxORNgdGjZ7 PPhrKSYrclYkR+8jLpYCD5YJIB0WP31/ZlTiK8tn5Y9ulMCocCeeSJ0LJXH6sEKP6zUtMj pfEX3gGQzASGinyKfkP79OYxN8EO/eo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Galj0vEa; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf14.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.52 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-5499659e669so787585e87.3 for ; Thu, 13 Mar 2025 01:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1741856266; x=1742461066; 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=oNVte8lvt8b44yuQA7mpFTfd90aDPPxxo5o7QBnVwxo=; b=Galj0vEacHPzkfgCn3QPyNvWd5LQaNpHdMxC/twveTgLGSQ09EUEhd5wttoO6+oyjS 40j1wv3gKqINz6BJFoHjCiZpR8jE1sI8om4Wo9wHgl+VOW31iaGw8rfDWRnrEBnjps2M jQkpPsFxPc43W3K+ncrtjoZNTdTT5671WLZ08UgnzWDhJRzpqY9pB+6d7U2neIJPyIT9 yoRknBhgN9/XjoDRQFXK2FPtlcY1RIOb1QfVbqVKVYlkPdF2odpciDh198hpTuJGd5E8 w3o0bUnbOKmAt0er2mchQ3MUoo0wtkx5uo4s9Ep/c1wrQXxm7H83lYBklBStc+C2bavU kifw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741856266; x=1742461066; 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=oNVte8lvt8b44yuQA7mpFTfd90aDPPxxo5o7QBnVwxo=; b=MWaXEFGHK41XzoCZxZWJvXmgdilsVVyTGaqn4L5omFJ1PpayfPB/NiO9S4Oat8L6Nz Fj4/y3/jQNncMa7gKQm+2JMtv/hpHHrrKOj67tyfygn1NQ8s2beOr7HufBOEbPKIOrrM 0wXofQdb31Xi8GgAXo1ZqNbhOzwWmHbr/TKEJdhr+IxRMjCwWyUVO5dvL/A4zAgvin8s DDXYOokW1I3mBGunpvLd6PrRDlJIaHjl2S7bwBMrcD5Fax1m2kT5vN9BeBp+XoceRq5T OqE3d+vO9JHQRldaQW+i8rJxm19AXRl8YA8+OZxCvs7lRf8KCY4VgyYiLCUjACXBnGvQ WyRQ== X-Forwarded-Encrypted: i=1; AJvYcCUaf/zc2J8d6SJovOE7LoGfXICUh9BUKB/BdIkXbMvTrUxVGmrtSfnFrvBMKEHKzeR/R0DQoS1cbQ==@kvack.org X-Gm-Message-State: AOJu0YweTBTMoxuNXDjjwqMG24G6hbvCMjjv88pPDeLEe3BFDMsrfgj6 +xGYuUBpR0U7fAqtPF2W9LfwBB9oDBVZOcKt0Rtx8pP3bs5Z/fI1WE+OW8TN/sQpszZlLWQI7vB I6trolhXxhrhD50mtIeyEtA5ZQ0tdIqefRIxiXg== X-Gm-Gg: ASbGncuhrWVuITA41uXmPqMLjrj7TyQQQIvVPPcAlLthZ/s+ZnEvcMWUrhUoAOyi7nV n6T6eTuZ/YMBP7Jgasn3cP81iux5YKEbHc2X8+pHknyJakQ+gaOZTKaZGDQq2gzijP4Y+EJ+hU1 5nijCq3Dzi/m9FN1O0m1zeIYINeEnkwii2GsdQpqsK9xxCDOB4UFs= X-Google-Smtp-Source: AGHT+IHrHgCaZK4KN9oZUVm2A3FprVTQvoB4+X6fONU0XmSiN2PgvVRMZuCwOSd4wSdmwbJZwo+uEPVOSQjD46oRw9k= X-Received: by 2002:a05:6512:3b9c:b0:549:4de9:c23 with SMTP id 2adb3069b0e04-549abaaad89mr3687097e87.9.1741856266079; Thu, 13 Mar 2025 01:57:46 -0700 (PDT) MIME-Version: 1.0 References: <20250313034812.3910627-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Thu, 13 Mar 2025 16:57:34 +0800 X-Gm-Features: AQ5f1Jo6rW2JENj9_ZucQSXxIKOzDShDlUIMTYmxGFUKf9EuY47aXkvY1bGOAW8 Message-ID: Subject: Re: Re: [PATCH V1] mm: vmscan: skip the file folios in proactive reclaim if swappiness is MAX To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , muchun.song@linux.dev, linux-mm , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 60A07100008 X-Stat-Signature: ugs5dmfz8hk3gkiynq5tsd4d37orykts X-HE-Tag: 1741856268-324668 X-HE-Meta: U2FsdGVkX1/fRWprTCxuIm64dxWQTfT2kepReCFWdzjD8cP7dn963AnNE15Ppxmm25FprTZcrB2VGcyxDlg8NPXCmK2q4nHTod999A7MraEDOXbO8XVqFjgBbFZktQ46YNt8nY8BDfGbqJsr8iU8QNLBCcBbFJtyzg+6usbsrazc5L/gzbieuZTf16uV1mf4GuCOTQjVXIjngtOfREQExg6uTPfJuKFM/Vlue7sOgNZfhvQllLUYYIVowhB720QZoh+oyXNTbJKZyMTgvc095ydADJnDOVBXBOL58gAkfqSuZOuEiN81b4yKiEfuxJ3iKcsElaswsU2iD5dVNQjc4y/263f3/gvlqpws2HF8OSveMHZ1Rs6c0LQnEXZEbZtNr58IEszOe/G4b57RCEQvAzxgwXlB2XwZUK6ppJudLs2kXBXKgCWb63xlTQRXFOtd0aHrZBYOw68nJ/8inGRsBIACiAt+jdvNJc3etrQxMmWmdIxcRSuaa/L2PSB0cLuWLrsQ+ltqNG8PF/VGQyuV1mb3l7tCdWatgAyLhO/QusN/HKHk1t52YQuz6Hh2UpkVdyE5b5i9CctyCgG8zsEwfbL7pKK6GsYD1PozE7ZAY2vWiNfb49mclD4plnhmE9QpRMSjLcdSo5MJSuO8J3YzPmdmfRS2I+CGn0T+lguTAeAYhxTw8BHeBLNoeZCp6jx9n+oWSDW5rDoQu4QGzWGoxorpckwj7wsoHL/sb6YEcLtBdBU0hf12RvLODvFWRPHF7hQpNqysqMz0F6ZDwjbPnnSfYYnFZwcpAiu1Os9hfGnDQjx4aMzPK2t9UmoTVih8hTwVw1PTDwuLWWe32RafU8rmGpsYb+URWVLJ71fk25Ler9sgzYD/dnL7h05TQCcd2Y+m1AkzU3gnn6po3oYkpV/aqkSiY87dxxY3pCEhs5gFaTO2adTdInSEVVNcRoltWDObjwUia0X98SDx1FQ Z1IyCNqU +8wrRoC1WJDW4hksHS/PDcYQxABVk5H/jeZJisgrYUvPC/NPT0Cq0NjuO1r8wyBLk1592eAH06D80QsDETcR1571kTzq/LEwLsAzaq32jL11ypjE42WuK3HTjUv3HijiQCkAjNYu5XNWGqpozfGgWD2rlWV4aF9PsfaE2KCcBoVrvLEgoUXu0+RciQeKccBVfKxs3Lw4uMG6YvhBMf4WBMZ9ZhaMxGMJ519mia8OlftnzNKPFqfHP5zmlw+lebueHbtbkdL63oQeJ96c= 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 Thu, Mar 13, 2025 at 3:57=E2=80=AFPM Michal Hocko wrot= e: > > On Thu 13-03-25 11:48:12, Zhongkun He wrote: > > With this patch 'commit <68cd9050d871> ("mm: add swappiness=3D arg to > > memory.reclaim")', we can submit an additional swappiness=3D argum= ent > > to memory.reclaim. It is very useful because we can dynamically adjust > > the reclamation ratio based on the anonymous folios and file folios of > > each cgroup. For example,when swappiness is set to 0, we only reclaim > > from file folios. > > > > However,we have also encountered a new issue: when swappiness is set to > > the MAX_SWAPPINESS, it may still only reclaim file folios. This is due > > to the knob of cache_trim_mode, which depends solely on the ratio of > > inactive folios, regardless of whether there are a large number of cold > > folios in anonymous folio list. > > > > So, we hope to add a new control logic where proactive memory reclaim o= nly > > reclaims from anonymous folios when swappiness is set to MAX_SWAPPINESS= . > > For example, something like this: > > > > echo "2M swappiness=3D200" > /sys/fs/cgroup/memory.reclaim > > > > will perform reclaim on the rootcg with a swappiness setting of 200 (ma= x > > swappiness) regardless of the file folios. Users have a more comprehens= ive > > view of the application's memory distribution because there are many > > metrics available. For example, if we find that a certain cgroup has a > > large number of inactive anon folios, we can reclaim only those and ski= p > > file folios, because with the zram/zswap, the IO tradeoff that > > cache_trim_mode is making doesn't hold - file refaults will cause IO, > > whereas anon decompression will not. > > > > With this patch, the swappiness argument of memory.reclaim has a more > > precise semantics: 0 means reclaiming only from file pages, while 200 > > means reclaiming just from anonymous pages. > > Well, with this patch we have 0 - always swap, 200 - never swap and > anything inbetween behaves more or less arbitrary, right? Not a new > problem with swappiness but would it make more sense to drop all the > heuristics for scanning LRUs and simply use the given swappiness when > doing the pro active reclaim? Thanks for your suggestion! I totally agree with you. I'm preparing to send another patch to do this and a new thread to discuss, because I think the implementation doesn't conflict with this one. Do you think so ? > > -- > Michal Hocko > SUSE Labs