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 C3CC1C3DA6E for ; Wed, 3 Jan 2024 15:19:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 522A28D006D; Wed, 3 Jan 2024 10:19:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F9B28D006C; Wed, 3 Jan 2024 10:19:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 399D08D006D; Wed, 3 Jan 2024 10:19:12 -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 2A8338D006C for ; Wed, 3 Jan 2024 10:19:12 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E0D2D1208E4 for ; Wed, 3 Jan 2024 15:19:11 +0000 (UTC) X-FDA: 81638358102.12.E265C1F Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) by imf20.hostedemail.com (Postfix) with ESMTP id 1B3541C0010 for ; Wed, 3 Jan 2024 15:19:09 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Li3nYPT1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of schatzberg.dan@gmail.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=schatzberg.dan@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704295150; 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=mkbPs4444YRyYU4hJG9uetQFelUwLH+/+EH+jJ2Bxuw=; b=3m+Zr1bW/RboINwvmFdv9W144eI3+d/KHkfs4i5hNJZIfaRwRzKXPzjLYqJHjrTtnZEDYU GvoVEMxcB+EB2j8yzhLf7DzzMxe7jHBzwVn09bf+iXWHFAvcH+WeW2fMubYNb8EMR5Km3D Py1FUqzuYhgAL9rKIMLFjWeQGiaqDJE= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Li3nYPT1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of schatzberg.dan@gmail.com designates 209.85.167.181 as permitted sender) smtp.mailfrom=schatzberg.dan@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704295150; a=rsa-sha256; cv=none; b=bJT1ZVyAChMkjb9/ssS11irkqOXbFSQDNYbp7dMWLh334fqhgJeQ4KDIkiuiHAIfovFLAL SE73fWja7IPWakhcNshxkq2poqKkGSsESQTRTNIBLj6w7tnkI7kC7qs3GgcnpiNGaJ3a4m b4iiUy8XlGSxNcrfUjHlRfnTN9dEvrU= Received: by mail-oi1-f181.google.com with SMTP id 5614622812f47-3bbc648bed4so5061837b6e.3 for ; Wed, 03 Jan 2024 07:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704295149; x=1704899949; 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=mkbPs4444YRyYU4hJG9uetQFelUwLH+/+EH+jJ2Bxuw=; b=Li3nYPT1ZOeNNs+kdn0aXqPdOh9QfO08kaae7N8kAUJh4TManRvBkXXD4I5fN7n8MT 892HaPVmEX96d4B5bqflekUj9cc/OlkyAXThitS56PNaEPetUEYOir5QLylRchlAvGB7 LxpHjhrMo83AmVL++ktMcRs4kx4ik2qwdRx425Cl2zm97RoYqsXBD63fL3NvJQ8il4OH cWopEvAe1loOW07izGF4Uuc3+DcCiDS0x2Nvg5Dyo3pqo4uWEZv2Hl0g3sk7jwXiVcmc i45UHQz08DmJcAjdSUvVzF4lGxxMUFo2WGr2XaLguyY3UkHL5EdaCV5khJGXmaYncvIh zTKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704295149; x=1704899949; 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=mkbPs4444YRyYU4hJG9uetQFelUwLH+/+EH+jJ2Bxuw=; b=GDejOKnm0gaGRtPqw6pWfJNPhTx5xUhQewhWkHu0Ca+9y2ROAIYGc+0N1wftn1ZZcI 2c7G1dIOSgzkKwhL62mYYmrjS9/gpH9kaNqHJL4mv4DAX39H4ghZ2vraAGSe9dyY0nNF nO2TTR1SFSpxQw7ibsA85rmLzfez/NBZxhI4IUrfODCdZtNfyOjIJKGmfftK1RTgI5Zj Bnr/sTotsHvpoFNFdpHBT+zjaiIKcKfcGPj89mK+INspRqOYgVWx/+o1xgRcS+obxHVn 3mU+FghNLO71ujwJuGD6igKS1ajchl9u45p9brH2Hj+zTX8iBY4w9WCg2dboag6v7dSr zbLQ== X-Gm-Message-State: AOJu0Yx/paQmjy8VdXRj1G65Xj1nt/W1a2rkzxt5BQqNqbZ4yqZg9WrS c6agQuGNqCm2M60iY4XNf6U= X-Google-Smtp-Source: AGHT+IE/4UtBydxpuImA+JNyF2+X+hT0PY7wZ9CUtkqSYxvv8ZWUgE2mBwuZmwOefEdh4F9Phtv51g== X-Received: by 2002:a05:6808:7094:b0:3bb:9b28:96c9 with SMTP id ku20-20020a056808709400b003bb9b2896c9mr16454662oib.86.1704295149182; Wed, 03 Jan 2024 07:19:09 -0800 (PST) Received: from dschatzberg-fedora-PC0Y6AEN ([2620:10d:c091:400::5:fcab]) by smtp.gmail.com with ESMTPSA id i13-20020a0cfccd000000b0067ffcfb0b51sm8323789qvq.139.2024.01.03.07.19.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 07:19:08 -0800 (PST) Date: Wed, 3 Jan 2024 10:19:06 -0500 From: Dan Schatzberg To: Yu Zhao Cc: Johannes Weiner , Roman Gushchin , Yosry Ahmed , Huan Yang , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Tejun Heo , Zefan Li , Jonathan Corbet , Michal Hocko , Shakeel Butt , Muchun Song , Andrew Morton , Kefeng Wang , SeongJae Park , "Vishal Moola (Oracle)" , Nhat Pham , Yue Zhao Subject: Re: [PATCH v5 2/2] mm: add swapiness= arg to memory.reclaim Message-ID: References: <20231220152653.3273778-1-schatzberg.dan@gmail.com> <20231220152653.3273778-3-schatzberg.dan@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1B3541C0010 X-Stat-Signature: 67jcrixc6xdsjg8udmppxomtfa9ws8ib X-HE-Tag: 1704295149-870504 X-HE-Meta: U2FsdGVkX1/j9kqrjZl4QQFcJyrUacU0iDsHz9x/PRxft+SGctHV/MUgBS45UT25m9i386J4HsDUcmIpJwX7MmSVeNU9Ma8IAmuKoB529iTDmpWBFHzaqDiLwW7LyX6p/QzIeOusXJgaNhZgzyQMr968/cWnDLIs0Tb54GPdwgUZ6TgBAaFzQQtdD+KT0x5M9fqUUuKaCMYZdnhHhdOIn+vjn4CKkp+e0se9TJ+TZ8RD41I0thd0nMJ5sMegwFMCQIlkECMcCUdg2k6v6KQsHuOg+yrxKzIlrfyPVUNMpvFqGandIk5IuFzC6dkwDHqNbprr9LlIiWDCokLhQFa4OuCMothndkuSTadI9bhLqHxrG0KLUQczYwQpEGT3z+q0CHLwH9gjTamRhR4cfI3ktnsd1P3bdLJ1KYGUMGt7PD50+/A3kxnaSpiFB9RuMS0nCvqfozCNRUh/EqitkgAfFwEqTwJ3ut7s31QyGcdj3cLrSCz7W5xNROeJLzB4WDXZxLZGd2IxAZI5ty2HUUldBtgVdIVOQrUeh77zbFAVoi3talSk5wiKP1Gu2CnuYRt1sez+IrchzvBRmyhVjXiSapvFg+OGRo7IhuIlHL8I+ME0GdaC8neHMDmUDvQlNxArGNU0PeVLHF09drYponZsG2G2nRwNkNeeZcsogPCQ87ymCUCz5+M0/pE1i3Kv7pj1QLmBVzosIXSazOo+laZAFqQKhT0yg/ORiVzzGdsBytkADHv7G6C32MqgL78EiDEPX4dnLeHZHxbBFEb0VqdXIlzCBN9jOkJ9vQQi9GaXKrSyvQQBG6EdTowcLgGuvgpE8kqF+UQDIjQvNqMLXp3kGEveOn0Cdcl8goAWDYkgCNUsIk/9arevnO3cNPnPeZZUnCOQk5ItQ1WrLpYnfyxEFRqkQjoTaAwGXpnMfz2nPEj5Ps/PKkCqe2HdAZkFgDLYJMOUtOqYX3nCHs28VA1 GPlNiZ9/ GB68FuNVwut3bamPFj73fG+cEfjavcQaQUYwDkacToUW20TwA/msuuQnHv5Oggj23tL2qqVShX53oqMgwdiLR+Mgnjh2ZL5opvs1Jr6jl9IHeU2Y5WLa/Q6x/K4YWB13WK5EzuzF2xutlGuzsih7BEUWIvu2MIg8ZzLaaaF7Wuo07LMwMRqyuidwNn8Carjo/e9ieYuliUaW6qKKY9ULWNvqtsacJWdbENpMy6bntx44Z/sqJ5g5M8dh733/oqJZ85DPMRzb/ed+Vhqa1mTaZX7dqzkS7zf5Ilm+aUtNTAVdcFwYMuciFMZwv+kuOnuTfmAfL42ubNzsTqEyQGsEf3BMqVuKnFTyhO0ykzWxAI1XQo7r8lencjItLtFvhQlAMlGepJI3xZhZd9DZLfvCE4oXUbN4CBcJpQhkZqgiXYS/F+0uI14tHio1XzZEAEWr/40zGHn5XjDe3X4Kex5shZXXaM2L56jEQ8rjdiMOYPjVa+4pKWLghfY5TD1YhbcDZj2CX491n5FveMRNVQoqNzCD1skXpWhf5jW9GwZXaJbVAfImGxhPEBtc1Oz5HCzkrauULyCdIagULJ6IFatuwYnfUggq8Ca82Uej/vuCjeFN8cQs= 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 Tue, Jan 02, 2024 at 05:27:18PM -0700, Yu Zhao wrote: [...] > > Helper aside, I disagree with this point about coupling with the > > proactive flag. > > Sure. But I would like to hear a *concrete* counterexample. > > > The fact that the only user currently is proactive > > reclaim > > Yes, that's a fact, and we should make the decision based on the > current known facts. > > > doesn't imply to me that the interface (in scan_control) > > should be coupled to the use-case. > > Future always has its uncertainty which I would not worry so much about. > > > It's easier to reason about a > > swappiness field that overrides swappiness for all scans that set it > > regardless of the users. > > For example? And how likely would that happen in the next few years? My argument isn't that making the interface more generic will be worthwhile due to some future use-case. Rather my argument is that making the interface more generic makes the code simpler. All else being equal, having sc->swappiness behave the same regardless of sc->proactive makes vmscan.c and struct scan_control easier to follow. That being said - I'm fine with conceding this point - particularly since both you and Michal appear to feel similarly. I'll make the corresponding change and send out a new version.