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 7A994C282EC for ; Fri, 14 Mar 2025 16:57:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E3A7280002; Fri, 14 Mar 2025 12:57:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 793BA280001; Fri, 14 Mar 2025 12:57:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C50280002; Fri, 14 Mar 2025 12:57:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4818C280001 for ; Fri, 14 Mar 2025 12:57:47 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C4375161403 for ; Fri, 14 Mar 2025 16:57:47 +0000 (UTC) X-FDA: 83220763374.28.981880E Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf17.hostedemail.com (Postfix) with ESMTP id B01FD40003 for ; Fri, 14 Mar 2025 16:57:45 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=nN2Albwx; spf=pass (imf17.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.182 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741971465; 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=2bVU7xRz9+BuoJ0Omh1aw8MsUvRzQCT7HAyopIIXQUc=; b=PSp8FwgtZVv1Oz73a2Emp+G+mTdJtB/DIy0uXGj89w/h1+CsnZhHe3g8kpTDNA+MalIOXT onEXkt6DMR/e7Z1UTLmdx9PjpkojlBrl0+toyhiWuvtWDeldDuYegjef8/nakzjh0vkr7L Bz/SzrreJWRRNxAKMEP8Tif0sh2sdtc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741971465; a=rsa-sha256; cv=none; b=hMKQjUbvVM3sdTjq+Gi78lr4ZkxXozbxcc4fkh/bhXXEJ8dJEolba6vzTQ0g0q57tQQQ1O VGRJh47BxbFQgpHxdmOUGkfI5HqqWApiuA5sFKibnYUBuKwe82cZ77cmVRqwS1WBAhmd5v m+RGsGglKGakgAZ1p9rKk4yw0wXgbQw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=nN2Albwx; spf=pass (imf17.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.160.182 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-471fe5e0a80so19972251cf.1 for ; Fri, 14 Mar 2025 09:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1741971464; x=1742576264; 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=2bVU7xRz9+BuoJ0Omh1aw8MsUvRzQCT7HAyopIIXQUc=; b=nN2Albwx/c5x4QLYjpH/17SHSpq/C0ivtfaJJHt+MNZei3xWZxUbR0FflNEiSeTerm vr1EcrQsczD7nGOKxbAcNeFT4j8EQ4IgiQggVXSY19RdnHyqorb0pq8gzXH2RJIStCC1 +VtE4REGQ/8QM7k22TNSaiV3Xq92qVelrTnoski9kNHGfS/F3F8bIQPor1ZusRRc0LkA Mz7DO6Eg2j5Afp/X2jKxZuqSPkSQw3f3ks5G17v8quRG23n7khVLp37pNQ/D4PMZfgvQ dDcET3lsQ9D94FmQrV/HIE4shh4871n79d8CBb4XMBhrRSnprKL4u2z9r/PVfs5lxl/r zJ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741971464; x=1742576264; 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=2bVU7xRz9+BuoJ0Omh1aw8MsUvRzQCT7HAyopIIXQUc=; b=FDlhKTw7BHXd3m3mc3SRRiNiSh2vbCkFRbUCfqJ6PeWi5Zu9Oo/6gbtpgMRjq+Outs GT0oiGSvC5knKMo58XpQ+hQsrv6eKlky0YG9pcHazmDgtUrxVdpIrxf3OfSEoV0d9err MvyBp2wC+27Ms+QChOUCmltweD8V6RmFJLHAV6MxY2fl1G42IqK1m4jxueLY8HODYk// OIgED1g0f5nEqPAA2fmS2DtKKUqiEznICgT4d0YtIknBBIw9mOqvb6kAQ7Cfy96g4OtA kIxMYn4/wR2O49Q/Doff1KwNVMlmsjMQ2eiwQYY68fc/OEH6g1QxJ4t9P6aIgtAZb5bI KOYw== X-Forwarded-Encrypted: i=1; AJvYcCUVpKjr0SZZnClADWYbmWOBSebp+1DJzZd6cSasy2vnq7fsmil3UqMgGivCupDD9/IilW9HwBFpVw==@kvack.org X-Gm-Message-State: AOJu0YyJis+P2RyYg6hxjvqeEd912VTNoUe2UrnVhKi0By7ipiuVt+FG LP2BRBHYRP7UUWgtqXZuThbfsqYIbvGoKgMFXDTfNIdu/vNJzmzprA6QJlBv4hc= X-Gm-Gg: ASbGncv707w0mz1wn/ASva7C0PcdQkhwUuGOlch6cpkHnnWD0/PBVALtK9gdJfspaCb /UfL3PaXckVX6J+EWWAP9XmNdNts8bDazZGbbFv0WNK2paorupWjtAU5dGr8/PK0T3nKJ8rALta hAZUnWYxyroUEgtfHLCC4VmvzIX8v/169x+2LZzzRfTCCuZK9GshPf/nxlbGXjQC9z7/WRFqFeL Eb/ffncbSSXs3YtKplt5vdsFVA6Ss+KVquaSaGe+sK0eNcmc1+UxNsWzApZW1BhE2jL7Mre85/B UH67QcJNFh/4hS13i8U1h8KcHAzdpZ0QEG24f5mxdt2OQQ0W0nGrQQ== X-Google-Smtp-Source: AGHT+IGRjUQU+0AC9eIw4hobeKQ9HxQMqF5ruqdLJhpFMzyfDl2DBx9fQrFgm3nT4YDNxDk/2xCZAg== X-Received: by 2002:a05:622a:11d4:b0:476:b956:c5b9 with SMTP id d75a77b69052e-476c8152ccemr45548701cf.27.1741971464531; Fri, 14 Mar 2025 09:57:44 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with UTF8SMTPSA id d75a77b69052e-476bb63baabsm25428341cf.28.2025.03.14.09.57.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Mar 2025 09:57:43 -0700 (PDT) Date: Fri, 14 Mar 2025 12:57:39 -0400 From: Johannes Weiner To: Michal Hocko 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: <20250314165739.GB1316033@cmpxchg.org> 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: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B01FD40003 X-Stat-Signature: sz9t7i4iiuwhpesoxk1k7zcm1fq69tf9 X-HE-Tag: 1741971465-892935 X-HE-Meta: U2FsdGVkX18+Yz0ehHhgWTNngjVhJ0MCr9G7UF2Oi91HoUAicIvSibR/QpIM0QdtR48wgMJfYRJo/cDu5Cum6dBeAcJzjkA5KMVPjN1l6OM0OinNgac5XLrJ74cw2SNwuNOJdfcWsJ4cXwbpF1rciMg6RKDzJ87ehxCcywKeXeb07hDJxfooLm1Me8MuIM9egSlr7S7lVx+NjWDYHISKytVPI7dCz2Mo+Dxn/MvQEHCGEyW5736mjwag13tKzgiNcI6ExzmDFbI9R3TmcHCiE4gpSRK3FnOnjPXTgw8TA1TInCA55SWvGNjL7DcXxUdgDb7WBZKXb4v8wNSKfdH0aN3/GfGLiAcRFGa1CLKpacSe8qACQIm6D2ma6/dKyXA9dbMzOWG2/8KuNoHqap0PcOsPbbiQdssWR7L4gAwgucYawATJIiwzRhJRonFEFY2YQVx/PCP9oRPCR09GuUn8BVn1yMh9Ckvip0k0p+1B/zMOEBbdYyRiF4PKfseLBc4hkqbbeFgSSG/eHjqNri4T1B/5TDCE53FS0aL+RMSVgKs62krU2gzJyr28SqOHW+z+lmsHOGS9k78yfwhD/GhuWr1B1XFaTnOygrUGV1Sns4LBTY45/BWSOKbn168bgNgvTij4iF9Q61WSmWmU/wBHevoUPtZkI/1/AxuBQ8s4aw0r/1In4BXk6Zlyd7smzESoy5E5IiUshYrWgMkqlXDjWp0HN4Q3eOq0YXhtz3VCCZuDP9jnL5H90yfzBuwY79swz8Dm8Ar3xAQIE1GuMJjMQZpMGXM/DwOgwLhrInXS6ZvsBrtEwHQRWhhRsDhtDBQuEtszK8h5iB3OGMf8qXu8zue0gr5C7k1KifzcC60CGoqou24FeZ/LeGwtHGzrbylxQ/OjmYYeYuz9l21l+UoKgAKGAHNmpso1u2s+rY45SQLMeKolufQmdUD4xDokqc7Z+AMyNso1zHcTO/5lc86 MxQsSWub E4GB2MNfLX+iG1srSg31dUw2aesP/FajKpVxXlFnrlAkEkMWqna7RJTK3knOizQiNLZy0mHfvQlDydQJlROIYv27ySJzmBBQcWJsrzyxCQ8LlzvloT1/E6XD40zkPpxUtEwdZXR0ZnAqITWqjcikwojUOqsPZlbrnqKnUrS+SutNIv8vroZhV8hO6wq0eFrEI9L51QhlLgNz9nq0fN7i/dfIp/zEDBGBHDYGODhBuBYWbxvbFhDZZ7IkXMAKAdaQZCi0VmCl1u3QSfFMS+mBjKyaxo+r380DkZxHxSzzxU0QnfgOJnE8S5ccDMeMxwwglrHyOlgHRm1zRiJGX4p7OUtG/QJj/rwYu0lzr6Wbhlb5Xm8SIYsMl/hJWNjgAUxFVHa13PtX7vbweryHv89jXWCpPSqBThPlkMG+cA55tQSZLSQ/48Am7x5bLAPG45om+KO3/fT+8XMTWWz757wf0vtOJOw== 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 03:49:30PM +0100, Michal Hocko wrote: > 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. You're still oversimplifying and then dismissing. The heuristics don't make swappiness meaningless, they make it useful in the first place. This control is used to define the rough relative IO cost of swapping and filesystem paging, as a value between 0 and 200. This is clearly defined, and implemented as such. cache_trim_mode is predicated on the *absence* of paging and caching benefits: A linear, use-once file access pattern that *does not* benefit from additional cache space. Kicking out anon for that purpose would be wrong under pretty much any circumstance. That's why it "overrides" swappiness: swappiness cannot apply when swapping at all would be nonsense. Proactive reclaimers like ours rely on this. We use swappiness to express exactly what it says on the tin: the relative cost between thrashing file vs anon. We use it quite effectively to manage anon write rates for flash wear management e.g. Obviously that doesn't mean we want to swap when somebody streams through a large file set. Zhongkun's case is a significant exception. He just wants to get rid of known-cold anon set. This level of insight into userspace access patterns is rare in practice. You could argue that MADV_PAGEOUT might be more suitable for that. But I also don't necessarily see a problem with making swappiness=200 do it; although we might have to teach our proactive reclaimer to auto-tune between 1 and 199 then. > 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? That would require the proactive reclaimer always knowing enough about the access patterns to implement cache_trim_mode manually. This isn't practical. And removing the heuristics would be a massive regression.