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 34A79C35FF1 for ; Fri, 14 Mar 2025 14:49:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 804B5280002; Fri, 14 Mar 2025 10:49:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 78D09280001; Fri, 14 Mar 2025 10:49:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 607AC280002; Fri, 14 Mar 2025 10:49:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 409EE280001 for ; Fri, 14 Mar 2025 10:49:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A4E991A11F1 for ; Fri, 14 Mar 2025 14:49:36 +0000 (UTC) X-FDA: 83220440352.30.36924E1 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf22.hostedemail.com (Postfix) with ESMTP id A75DDC0010 for ; Fri, 14 Mar 2025 14:49:34 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=XBGpGOM5; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741963774; a=rsa-sha256; cv=none; b=JPjXr557yQ0XmBZMrdTTNVnSQMfBDr1U4zQQNfxR82TYPTISjV/6JQOeKbFixGhHGjmnp+ 0gz50fClEi6jAh0ZDUkgZlBpfHUC9lvEaML6CU21X/6IKf2HG0Q0uO22vO7zr5n5zIJgq3 P4Z9jj8QJj2FXJQK2awjecoBdhzUf1U= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=XBGpGOM5; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741963774; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vaYWZrrXVhr81EbJfjzrSCaLmcRbDWo2bd4uQl4U+HE=; b=X94QZG9Cd1CM2Er1H/cP3jMF6Thc6zJQRtbKYijTbd6a90z5zG56/UgEURwOr7cMOsJnp0 yGQl+zu39R7dvEUHhfJLGULNb8lqyXQjUdX4ZSFa1q8YXrCcSjZzMifHllMt5H+UtChqk5 w2vUuiB6tAg49a48YH9duzQ3wiuvHrI= Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5e5deb6482cso5871716a12.1 for ; Fri, 14 Mar 2025 07:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1741963773; x=1742568573; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=vaYWZrrXVhr81EbJfjzrSCaLmcRbDWo2bd4uQl4U+HE=; b=XBGpGOM5lyGK2/xDbc92+uK/BXnIs+Y2AhFj/kClHv97Zb4oGiQnVJuMgSrvs8Ahx/ +NefU1rswsrZN5cYItFDUPwL74hE5psiHszFuATnHanC6JrPsEG+Jk19jAs3/y1xZuq3 Ettp7EI8mLLDBPwFcMIIfUiHQeutMhJmuITPZ6NTyqN0xBX/lu3yl7GpEVnUuY543oxK OCbZ57gItRmE2JCiBLNGT3FgD56iVbpAjd6b5O2Db4vZQYuVaB+uaMCCPVTPY00YVfTX yi5gVk+MXSFFGqg/d3PMg41/a2WDlTaMuFbQhF7VjOQU6AcMBGpwyeH/enuqnsICqVuD rdlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741963773; x=1742568573; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vaYWZrrXVhr81EbJfjzrSCaLmcRbDWo2bd4uQl4U+HE=; b=EcQlr2uoituRd2GPd3F7z7N8y1apNgEOOt3fpLMRqcmrd/6L5s757yLQjpgb9UeY+I n4toZ0gt5ZbA+zUUF4kufzoXtTdpTYEUiw9IJn+8uctiMyvc230AGjI5U5jMolNRH8Tq /mpCSOWJw1ewtnQzmIocjweY7lLrdm2lVN87kg0Qh7Y5wk5eUf5RuIvc2sM6qEgEAZUn oDnePGFy9JDmYHCyXdy8eUGUnf7cwPaNkwTsA+wa4bsPEyVSnd18qThBz1GMHmey/H8e Z3VVmNls8tyWB3dw0uTAv3Y/LkAwv3O5l2S9DK9xsQ3qeQ9ylD+7irOSEgunfk87Zuab Zl4A== X-Forwarded-Encrypted: i=1; AJvYcCXV0JKcZtBKG5tNq2KOlIsX0ZPW9PtRSsOVFinV4N09DR+1AdoHkL2MeSG61zoIBAczDtEtKwDWVg==@kvack.org X-Gm-Message-State: AOJu0Yys3Lz7OIji/LIWjx3IzdQxeYGrd31fg+93Qi14UEWkrOtopEDw /y3HP7DpPvbQCF1EqXQBy9Jo2xJJC9azTUoAztQFyOHVRqKnKADrJK2rLTLHSslU5OTNyVz9dOO C X-Gm-Gg: ASbGncuQnUPOgANtEoy0qrAkDjXlvPqJO4xbpOhp0NAAfxl6pbiGQywRb85KtmuNEd9 rSn6wJyjtjRxns1QBIRtQ1VZjCDUqb7zEtfJIX70vGGYjTe63a2a/Y9js9tr6a7sbU9Ta1jweOf Fo1odoeeZ3fmLaGEyPa96DDR+Gs8no1WsaiDYxSzBGAjyGOB+itjzDHS07huXvQcgOT6kUuAPrC xhkWVYj6CbcvY15sulKiywNhnhS0Z1qWCYVgpifIIrHnOD5/v17JIzuK33CLs41MkoupfbRgsjs jDEN/di57BzC9uaw8IpDNGJNCAoxZkhhEYxNHmjjNOEqNecG1v0motJvYA== X-Google-Smtp-Source: AGHT+IFuZcfsNTicbAsGSdC4hoUDrMHk9sk4gAEvb2ZxuSm7mdfAF9+7SV0Qz/gkzMlJVIiYFvty/A== X-Received: by 2002:a17:906:c147:b0:ac3:d1c:89ce with SMTP id a640c23a62f3a-ac3313056d6mr271960666b.9.1741963772281; Fri, 14 Mar 2025 07:49:32 -0700 (PDT) Received: from localhost (109-81-85-167.rct.o2.cz. [109.81.85.167]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ac3149d0bfbsm237138266b.95.2025.03.14.07.49.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Mar 2025 07:49:32 -0700 (PDT) Date: Fri, 14 Mar 2025 15:49:30 +0100 From: Michal Hocko To: Johannes Weiner Cc: Zhongkun He , akpm@linux-foundation.org, muchun.song@linux.dev, yosry.ahmed@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V2] mm: vmscan: skip the file folios in proactive reclaim if swappiness is MAX Message-ID: References: <20250314033350.1156370-1-hezhongkun.hzk@bytedance.com> <20250314141833.GA1316033@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250314141833.GA1316033@cmpxchg.org> X-Rspam-User: X-Rspamd-Queue-Id: A75DDC0010 X-Rspamd-Server: rspam05 X-Stat-Signature: 9dzfy374e7r459eaqtj7ma4jpiab695k X-HE-Tag: 1741963774-153720 X-HE-Meta: U2FsdGVkX18Hp/19sxXs5nFuH/aZ7g9DUcoNA1Z/gOwjTWUAPh3bA/ntqyfNjC7MpoW1ATYsxUFQjw9y+ZFK3vQl0M0wTA1TtrUun0UAhOxUk2JTIsGyT1PeK3FFR0KTURaEsw5cfRhWzz/DZOzjEPBfvW+P8gVf/037pQr061cXTI0shpe2Ydk3Wqq1W98JHZswHh229kksYRu9zd58/ZRCk5ODj/yqNuXxkdF2oXodTIlpF1T+MlxRIsb4r3kM15W2CaiCh6VI4kLbrALE/kZmJqJRa7rc7p//6QVbQ7X5vd5WnwaENDuEjhlU3D8vNfdEAE7Y2d0oo20VPUxE8hrKKFHLZsGft0bteXeumRXaz4c6OiF2kMfmxWWTkfGmbyfRtpYmgDAU9A3cBQ44jCU9ZNdz21Wm8H3mnPj7ms+R1HbdkIGPM2pKj0oRxn9wtmthekNigEpu7Im2z51GxHUSXn1g0DLnDfePSY+f1Nz9ZKhF/wbiq6ULJ1NRN1tKH/0+jsM2xrWL9Nc2/7bMkuYyagxLNcBOkUHo8Z8+HdHCVD21gucElY0QyKyjtSS8q/DJUrEi5RcZS9jo9597wKi10wJQei70TVJP4/L3gMbBXf2nFGSGUQxwGxJVc7VOyOwE/a5CGe0+KwkDUwMwXRPaLbdRvRZo7zRunSN+7jJ2Bia4dSPw6lKiSB9Q2+9ERnTfI6kr41kFltaRZPEG1bysv2NIAUGcSk6brHXAiDMePr5KvThYwfShrTQe6Ey/ndzSkbTrtjLXQzk0ubmNQvSKjBiN4Nm7x0dN3lllROTVkg7DEqVVCe+vCbN7mgQw9gatvGOoKj4GL0j3CmwhjbkJUcp/FYOabre9LlSHrUHXLodswzkFkD4ZbOb6RP/hk/oE2t2TmKFBgtBXuFCaSI6lkSaIwBiBzQ8uhAjH2PVK1rDTvCq926+/8WG+OFFl1A4WeQqjfUaLBt4gJPG c265uRbq w1ufORDNHWfVL8fsY7sNqaq6W2IMB2S6Do8n9rNNp86Xcr3es31kCgI4IsJdiTVSsoFFCAkuMJusnCeuppCElcbSpmSrlxS2w3mTA2qdqes91jMk45riKy2bZzbo1m5nsQFLcGQq2oOy5wEHYG2PVb20VK+JAhOqIfPNEy7UESy6nhGxn+CqzVBhIxJ2Rm9mCrCk9icuh+lSxebNEPuxy5lIl7blsV5Lush6b6WV/0GG2WU7eCAj4rb1MsFULE3CEr/nfkqPKwKRUEHKqOb69jJP6vGWgI7Arh8jy8iC0Pv7Z7qgEKkbVWcnKrIVCkJRkERK/ 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 14-03-25 10:18:33, Johannes Weiner wrote: > On Fri, Mar 14, 2025 at 10:27:57AM +0100, Michal Hocko wrote: [...] > > I have just noticed that you have followed up [1] with a concern that > > using swappiness in the whole min-max range without any heuristics turns > > out to be harder than just relying on the min and max as extremes. > > What seems to be still missing (or maybe it is just me not seeing that) > > is why should we only enforce those extreme ends of the range and still > > preserve under-defined semantic for all other swappiness values in the > > pro-active reclaim. > > I'm guess I'm not seeing the "under-defined" part. What I meant here is that any other value than both ends of swappiness doesn't have generally predictable behavior unless you know specific details of the current memory reclaim heuristics in get_scan_count. > cache_trim_mode is > there to make sure a streaming file access pattern doesn't cause > swapping. Yes, I am aware of the purpose. > He has a special usecase to override cache_trim_mode when he > knows a large amount of anon is going cold. There is no way we can > generally remove it from proactive reclaim. I believe I do understand the requirement here. The patch offers counterpart to noswap pro-active reclaim and I do not have objections to that. The reason I brought this up is that everything in between 0..200 is kinda gray area. We've had several queries why swappiness=N doesn't work as expected and the usual answer was because of heuristics. Most people just learned to live with that and stopped fine tuning vm_swappiness. Which is good I guess. Pro-active reclaim is slightly different in a sense that it gives a much better control on how much to reclaim and since we have addes swappiness extension then even the balancing. So why not make that balancing work for real and always follow the given proportion? To prevent any unintended regressions this would be the case only with swappiness was explicitly given to the reclaim request. Does that make any sense? -- Michal Hocko SUSE Labs