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 DCB89C28B2F for ; Fri, 14 Mar 2025 09:25:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC64C280007; Fri, 14 Mar 2025 05:25:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E9C06280004; Fri, 14 Mar 2025 05:25:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC874280007; Fri, 14 Mar 2025 05:25:28 -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 A9980280004 for ; Fri, 14 Mar 2025 05:25:28 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DB9A9160E0C for ; Fri, 14 Mar 2025 09:25:28 +0000 (UTC) X-FDA: 83219623536.03.E132579 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 503AF20009 for ; Fri, 14 Mar 2025 09:25:26 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=NLpb5dXU; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf13.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=hezhongkun.hzk@bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741944327; a=rsa-sha256; cv=none; b=eAnaADQlYpOFnAVZeu6Y/HYT6nckELuchODJq/lgl2vF2LuMp9z5YTwfxayXlGwOEEd/Uv +273OFKss4NP+Ltr99/DHKTkBfj73Z3GqcIbnnE/C7NeyG4jVMkA5aAwKlrMmmczTKU57/ gRIuXQjxX5OAiJwWPnmkIugAhv7sLng= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=NLpb5dXU; dmarc=pass (policy=quarantine) header.from=bytedance.com; spf=pass (imf13.hostedemail.com: domain of hezhongkun.hzk@bytedance.com designates 209.85.167.53 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=1741944327; 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=OdpgR/K+jG8H9Mmix9bCdPdwnrgEiVRubiQLwqas2JE=; b=TCeATgentVBs10jpmIBmPKf7yXFRvmAiNupMpJeydIp2Ah4zqvjhdAEI5OUeVNBZadw/GX Kzxp9D6oh+Kb/Tnp7Yl8+ZJ2uzyG4JMNYeHVoi6Tl3YRVEzrf0UuIN7TInsvAYvjfcCGcC FD5Tmp7vehc6FeHTFsgfM2O2zEnGJGY= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-5499659e669so2106989e87.3 for ; Fri, 14 Mar 2025 02:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1741944324; x=1742549124; 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=OdpgR/K+jG8H9Mmix9bCdPdwnrgEiVRubiQLwqas2JE=; b=NLpb5dXUDTPYAxgu+zZLS/sidsj4SvhNaQzh+M7kK0Wefm1KYfX0VW5x+gtkdZpuwc G2ED1tAFFy1eDJOL5n1hjpm0I+hRNe/8Hw/8+zG1w/VUTTJPNpl803NAWflZIPL4NQNc hByPTileSmzOSxkp3DI0CPKKrkhOn7/oWWf1lkQzR5ijL3CSAguZ8+YkLOzMc3Ge0jKD LLeFifoBmp3k7vik8MtmXW4B+Bf4GZRIvsSKNkTmanfY+6HsO7HEzB33DMn+Un5o6OoS HU8pnFvt/Hd/bl2y62CjM4R3rmEZN1ztuIW9GNeKacVR/wCfObUqulDGmeXFzSnb6NpN +7XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741944324; x=1742549124; 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=OdpgR/K+jG8H9Mmix9bCdPdwnrgEiVRubiQLwqas2JE=; b=Cu9E6p2wap6yzkiz7yA+4YQqGxMf4wNNvQJ53ZWmhBE6BUyUxkXVd48+XCcVqCXMkQ uht4TfkWESbGPQx9crXDJUmLZnSO2hwd/pt5PKdMlue+IBRD8d0INF4g/E9YHLzyVS6C BVHvKV7ZmFaFwqKU73gw5LMtCcL8oKmDSCBBJ6oOyIC7ukDTaG5YVlF6F9r/Oc0aTI+w o45A63BFRBF2j+PCqiJhcbhcO7QXZJmnBJdEM1gYDrnXqmbABqXt+o6Am3Ocz6Khv3pf HPZdRyOe7U+OwqoXGtEENozhe62r3g0ysaNNQfgmTc3swWyVGVLcHLXf/9vZCxizZQ8N TSPQ== X-Forwarded-Encrypted: i=1; AJvYcCWQFnoLJggc1baE+H+C8vJu+qeReAxGMgGEFBSr2+gJt8H/QngVn99FLNqFSThiSKNIGFwgkKBz4g==@kvack.org X-Gm-Message-State: AOJu0YyduF8MLFMkRzg+HeVJFfl81Sm+92Q2iThxbYYevmd19hIbmP70 dvOJyy5OeKJTZ+cru2CJ9iJ8U/JYT6SOXxpE2No54seS0taW8AWP7XOIEt+wXYbn750wM6ef+J1 SdzJM4diqx/OyqMc1AYs1yFJQf0WehaiPMIkvXQ== X-Gm-Gg: ASbGnctG+OY78Na9kCYprmPsl1oNtQo0Z+K14TrjEDX0Y3DkZJntg9Jtxo3uZWdydzI 2Wl+CfTC2hP2JTwd2wA7Nf/6wwmnwNiEHrJRDljKWNIMM0XaVyeCWF41DfMKAthlnV+7n2RRvTq TphTaj0R1nwXrUq4mF6e0z3SeLKaVlKM6zUKyYXNU= X-Google-Smtp-Source: AGHT+IEjVen50YVpwUrK456NvIgY0rwkW0OYrnlQs6iiVW7g/V8zHkeH6055LHMjUjoDNm/N0Eo8uGzNKzgcUV2w3yg= X-Received: by 2002:a05:6512:2216:b0:549:38eb:d694 with SMTP id 2adb3069b0e04-549c3913c35mr566242e87.26.1741944324144; Fri, 14 Mar 2025 02:25:24 -0700 (PDT) MIME-Version: 1.0 References: <20250314033350.1156370-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Zhongkun He Date: Fri, 14 Mar 2025 17:24:47 +0800 X-Gm-Features: AQ5f1JqB7zSyjpT8_t67e_MWnk5d31Q2OfVpYekPNjXCTE9-Bw2QjQJ5WgPleAU Message-ID: Subject: Re: [External] Re: [PATCH V2] mm: vmscan: skip the file folios in proactive reclaim if swappiness is MAX To: Michal Hocko Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, muchun.song@linux.dev, yosry.ahmed@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: amowzweaj89asdajdwy68p1dkf8si1t5 X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 503AF20009 X-Rspam-User: X-HE-Tag: 1741944326-634876 X-HE-Meta: U2FsdGVkX1+0L8B9Q8KevIT44uHOr2oQDbqxQO+7O+oAyK8/0VV7ocFy0A2dJ/Y9momL/hA3zuk/TM+/2DbTziJnqb+RmcqKlFBRYxv3FNcndw1cqh47S24z2B7BcdWdCU9zsSfemYjmBGI6AtOa2phb+yWQgsdMz4NxTMDPShm21VsgjyQP+4kERxsmW29OeYTacfCSLiyjubuEbjaBWwL2W6Gbwmr0kgtOrr4HRVLwtxTIVpC2Dj4GzGrJqGR6UYrozPYMgqNC9mXy0G0PhzVCzm+BxER6qDZ0z3gsSIpBNMgIhuaZwKd137Zq1muAGJueN4X+DH7lG/VEpChwExCkkWl8ONZCYqesAERx8JBdGaOC1mNw9Niqhy1a7PMVT9yLJMLXUqseLtmz8SgNPTMkOmkInMJS/uHKpzomZCADoe4CRHpJb59gsouRVXqMJwz8fwfvoGTkFFIGp9os3UN3lW6Fxw9dzTVb6omu4xTR0qHK6q0jlfyVVLImohWS4jeKLfQ3837Mb8cxGh2RZIMvsx+BLNWHbCvdwFkKt1hK5qHARmgUF5xyxIpImuE7zcXn1PYEU5FI8hneNZw+8wqPg0q9xIf3RU3jU/qBq05MqnUNVij9AheiR2LCQdRMgskoyLhFutcV9Wxl8UqsPyfBBdy7v7yrak+UQ1CU+YaoqkhPY1ysx7XdT+UP2d++t4vFaBGMLPfOm0/u62osoUCHqac03IKQ0ipbS9kzyXd5R+I0Qnot5msvPq0C8AYxntQ7CBl5l8ccZeYUmXIa6PLLKlt6FsQM56z3u5dd/70XfZtmM5kHji/VQ4OjlcnBpK45Gw3BgHBOxZqfca9PHF6vloi9JEa4sebHQK2TnxjAdHMff9YOqWnT8TVmZRzPp8HV/2nDfXwd+i/wmmZwSAviFhbFd45e1JmLEsjgq4jUDw3p6AIUo9heXQA2bsCQOS+hC/nwnSw7jPHzG2N m4uGuU7/ lAGc9YHfLmtJt+CK9uKw+GnBpUGtkKFcRy8kmpWtMgmDYR+ahYxl4Wz4/0w6vRPSUj2+6meBKhWsY+JYG4h1ViUjsMzzKBgwHsh1zp2J7k5VYnI8DdCoWXKmddvu5O9Z098AOHelZUKfO6qIC9zjWhb6Qm3QTXe0W6KbFd5M+01104lg9mriQa7XExMMy47ByYkXEr64I5atSG4hZVVXqiPhIMBGzUjRXc20L1BbhxiG3d5mgrXWv44v9JZBnP07o7ieZI6eIKs2bylU= 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 Fri, Mar 14, 2025 at 4:53=E2=80=AFPM Michal Hocko wrot= e: > > On Fri 14-03-25 11:33:50, 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. > > Haven't you said you will try a slightly different approach and always > bypass LRU balancing heuristics for pro-active reclaim and swappiness > provided? What has happened with that? > Hi Michal I'm not sure if we should do that. Because i found a problem that If we drop all the heuristics for scanning LRUs, the swappiness value each time will accurately represent the ratio of memory to be reclaimed. This means that before each pro reclamation operation, we would need to have relatively clear information of the current memory ratio and dynamical= ly changing the swappiness more often because with the pro memory reclaiming, the ratio of anon and file is alway changing . Therefore, we should adjust = the swappiness value more frequently. The frequency of setting Swappiness to 200 is relatively much lower. Do you have any commits about this concern? > -- > Michal Hocko > SUSE Labs