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 AF32CC4167B for ; Thu, 30 Nov 2023 18:49:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBBD76B0474; Thu, 30 Nov 2023 13:49:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E71926B0475; Thu, 30 Nov 2023 13:49:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D33978D0001; Thu, 30 Nov 2023 13:49:52 -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 C61866B0474 for ; Thu, 30 Nov 2023 13:49:52 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7FBF61A02B8 for ; Thu, 30 Nov 2023 18:49:52 +0000 (UTC) X-FDA: 81515509824.22.A003645 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) by imf11.hostedemail.com (Postfix) with ESMTP id B2C0D40003 for ; Thu, 30 Nov 2023 18:49:50 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=m9Bmc6NF; spf=pass (imf11.hostedemail.com: domain of 3TdloZQgKCNQI70A44B16EE6B4.2ECB8DKN-CCAL02A.EH6@flex--shakeelb.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3TdloZQgKCNQI70A44B16EE6B4.2ECB8DKN-CCAL02A.EH6@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701370190; 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=4SzgB02v3pm2Y/9qEgT9NgIXu3bggWU3e+JewN/6J2M=; b=YGAUB/nhFS0l9zhrWZGEMm8Hh3VNo9OsLhtplqOILpelX0Wes1TpBJSvaCibYyHy3nmB5X Qjk7zrJ1ApvW/yM98rotFhgkipxgFMZAO9PUWeKDCDc1XbOoUygIVaf7BUkIpjqkQXexD3 vk6nOQk9MPbQzflwZwzUfvGrA94zr8A= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=m9Bmc6NF; spf=pass (imf11.hostedemail.com: domain of 3TdloZQgKCNQI70A44B16EE6B4.2ECB8DKN-CCAL02A.EH6@flex--shakeelb.bounces.google.com designates 209.85.128.201 as permitted sender) smtp.mailfrom=3TdloZQgKCNQI70A44B16EE6B4.2ECB8DKN-CCAL02A.EH6@flex--shakeelb.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701370190; a=rsa-sha256; cv=none; b=HYkZ87/sz/a/dv71CLVHNsD/nRjwMu85d5B4NQVug7Ic1l/rpY87LDE4XzSn4qln6xCflY XBtk3sgDgPFQ6hC2M7VTWz9lRlFDJ7uLQI+DkNez0JXyo49phi13Uzs/pCJhJR/wGDfIEY bl7EsgbO8SMI9yBN80VA5ZtOszwMjeI= Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-5d3eafe3d17so727967b3.1 for ; Thu, 30 Nov 2023 10:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701370190; x=1701974990; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=4SzgB02v3pm2Y/9qEgT9NgIXu3bggWU3e+JewN/6J2M=; b=m9Bmc6NFbrZwXIbBmUosWWzKQQqZGzQwVzqSCdrjkPY/cJorgdXbcx+haEIWIx6csP A+B2p/ODquPfdZx5cijQd9hKrkddByTFEvcZJuJjvvhcg0L/Zsmkdmf5KxP7IKj9LinF GmieRdqhtllueN8rWdRbNRre5UPfZeDXDyW2JjXPWqUIehI6GDeMuU6t3gmdD04cJmQB heyBck9+AhODdDau1yEXJglMY3SeAcLO2ZvpFNeq0xYt4Uamt5w81vT410mNY/BHaaGT S9TrhBBRvdvQPUtyaH2KKr6sImXr2d7loXfI6gpimFDpX3NK3HJVmG5JjzDFXRn89AIZ fLLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701370190; x=1701974990; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4SzgB02v3pm2Y/9qEgT9NgIXu3bggWU3e+JewN/6J2M=; b=rVR8kmIAnO8UdEJnL+eJmJc1Oha7DDIGVqE04bfKAM5J623GsGsRwXRS8Zk0MvieKj d2VY8SRRsGGK2aPi9+BUZ9PSYyJDbRHofM3DiaqozLSISymAN/vNNJ7S8aMTM6voEmW9 NqdsG2kE2mCStltHqWZuA2pPdBUAaezH0O1tcT/OVbzdWyCTnqA2+iwHI68tzatFnHfq y+8osxWK6EoWXXxA7sl5uWD0st4wkXKOLGOFCK6iT/CgGsaG2891vfsETn3MSANC8GrN oYhWpBihsAgxXV5ffKM8SwbUvMt63HSdi2ak/14PtaWK2b7e2XRcEsjUV5bAX97hAwUB UkDA== X-Gm-Message-State: AOJu0Yx6moT0vNPrP0dga4uldfVkpYprCFnP5YrCf2Fe85kiULu7hB2o SCd2VE8mWS+jFhX69kyHs6qpwyqWVCHhUQ== X-Google-Smtp-Source: AGHT+IFua5sJxKKwzjF614J8ZWN1/fmR30z+ohOLNRCyqzdzcqilwqXd9hF/oOB4O6XstIxY1N+wNq1MagdZjQ== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a25:a4ea:0:b0:db5:378f:1824 with SMTP id g97-20020a25a4ea000000b00db5378f1824mr135734ybi.1.1701370189834; Thu, 30 Nov 2023 10:49:49 -0800 (PST) Date: Thu, 30 Nov 2023 18:49:47 +0000 In-Reply-To: <20231130165642.GA386439@cmpxchg.org> Mime-Version: 1.0 References: <20231130153658.527556-1-schatzberg.dan@gmail.com> <20231130165642.GA386439@cmpxchg.org> Message-ID: <20231130184947.ina5qjymijrphibq@google.com> Subject: Re: [PATCH 0/1] Add swappiness argument to memory.reclaim From: Shakeel Butt To: Johannes Weiner Cc: Michal Hocko , Dan Schatzberg , Roman Gushchin , Yosry Ahmed , Huan Yang , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , Kefeng Wang , Peter Xu , "Vishal Moola (Oracle)" , Yue Zhao , Hugh Dickins Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: B2C0D40003 X-Rspam-User: X-Stat-Signature: eho41nppcu7opy8pbyhz9yaotafnta95 X-Rspamd-Server: rspam01 X-HE-Tag: 1701370190-497358 X-HE-Meta: U2FsdGVkX19hLTHi+gMJmsN8eXAmL73b91P+/X23H3DCo5+7q4mhKarsmGLbN8CJHtQC+dvyAI+pa4y5F1zaZZ5pAmfNeag4Yp7U8gQWRE4l4H0Sy/yV8i+NgXcdBrZeZIo0rUkiXuhP2y+Bm2HyODyx815SrbYaxacs9zAndvxvBzhMRN0619wRMKOcFgUjFkuSaIsTGtkuysohjDr5memzFbGm/3+B+Z5kzVsPiCTX1i+9M0kxHt4Qy0bu1IDLs/+QHptnY0oejGYZmebEzkMz8ElK+tzJiIxP/vDwzte7hCKYg3hTBn84idH8g6yZCBqQ0ZXl9JGRkqfKGHGd7Gil0pZhrL115EbHw2whsa7JfPUUzfu2IwidxwdOpnik5IKI9S3H0JWm+WPvJujT+DS/G7lA8vE1SoSEoHot9gIn1R9JniiLzU85t71lhCAFjYjk3GOa1Lc7cVKFFqlv3jKuKCuOh/ZDsstA1DzyK45SYZRCLR6PwEaNCCaIfekimV9QcG5hMYTMwExCMcmW7iMcGt8mVMTxplaYAnrMe0IVJyuUc0XDK0QuB7hbp+40kPSi7Uw40R4DMlzuyIu4LNC/JcrKzptNWntpWdGmcKeCNVjZh6nOi1/5i8BIAdbAwjBSbPj4f1JtZYNhp1CksgrgaVijRsohxqPYyjINV3EdIRJe4l8Rw5ykIdb55AZXyyiIM0w/3Q2iyYhlXvk5mlkTvjItWtrcuJfgogu4qUfjpxuKqBbDxv4h08/COlYzUL3PlW/xclnMOqVDZJw52ITjjRn+JfVwySoW1QF9xpkSL7ky0tNuL9QMsH3/yke15TuzsIkYX00k0O8JTsybQkmlShw68er3raZLvmvr1NQBnU30oJ3fSbO0o8788lT2YWp9rvGy0dFYp+ohYmsN9egrtPGJIChOAW3HKvVhXTM8Ur2VN3nlA0+RQHve12t5ZMNt7QEWTLl7Ygip50e n8An4ZRt B/BH57KuZUPWv6z/XEPCtu86cNFEFTfIz7xbsHqqD6dYSp2K04HuWpiBfMLPmRk2YqcePJT3GXFaY4gXo2rpLGGHqg9ohZuOaeoMLRpPASZAjnvrZgzddf/f6IdTE2gmwGUCs0KyX4X7T2cHANHNb1ZiPFWQSh2EosstnGFNJvrygqXBZSCKq9CAg0lWD/bKZ/XleeKQr349VZtzDLzMjt41JyOX/s2RMOKRDZKh5R5Y2fdZSP5alby4Xdb8maNm2RNJCMjormBe2xqPZM+4w2to+JZDsdau2spVRh4SVdNUHxJrSuX8capehu/EwZw2J63J+9NXU/05rerrYv8Mhx31Sqh9DXGyUE5TcShlPuxhSEhYdWhxDaGzryCJgrSaeLhSbVdkNlZU8h2YvtMsTkPyNDNiCLH4icBxQVe1T4c2YsNsd9Czy4FCnAfKWWXjdRR4H4MmYg3ppdY5Txnro14XcBt9gFhxUQlgKdmlWd9gZspXg8dBtXzQyxT1JpA+2tDgb0XU8JfLi6fjnfD9vFwYnhZXcWuiYJfLFAZCT+1FjHRqLNNdLvRoA9idFhhZp6THg/MfxPiE+bphSA5QJ9mhI0qCkzSJFZ0e56xJ3UiD5EBe2+9Wg8SllLr1BEP/2cxykB9wWyM5s/2NwiUsS8PFqPj23L3z8GMPUl1B7eisdEIU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000024, 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, Nov 30, 2023 at 11:56:42AM -0500, Johannes Weiner wrote: > On Thu, Nov 30, 2023 at 04:57:41PM +0100, Michal Hocko wrote: > > On Thu 30-11-23 07:36:53, Dan Schatzberg wrote: > > [...] > > > In contrast, I argue in favor of a swappiness setting not as a way to implement > > > custom reclaim algorithms but rather to bias the balance of anon vs file due to > > > differences of proactive vs reactive reclaim. In this context, swappiness is the > > > existing interface for controlling this balance and this patch simply allows for > > > it to be configured differently for proactive vs reactive reclaim. > > > > I do agree that swappiness is a better interface than explicit anon/file > > but the problem with swappiness is that it is more of a hint for the reclaim > > rather than a real control. Just look at get_scan_count and its history. > > Not only its range has been extended also the extent when it is actually > > used has been changing all the time and I think it is not a stretch to > > assume that trend to continue. > > Right, we did tweak the edge behavior of e.g. swappiness=0. And we > extended the range to express "anon is cheaper than file", which > wasn't possible before, to support the compressed memory case. > > However, its meaning and impact has been remarkably stable over the > years: it allows userspace to specify the relative cost of paging IO > between file and anon pages. This comment is from 2.6.28: > > /* > * With swappiness at 100, anonymous and file have the same priority. > * This scanning priority is essentially the inverse of IO cost. > */ > anon_prio = sc->swappiness; > file_prio = 200 - sc->swappiness; > > And this is it today: > > /* > * Calculate the pressure balance between anon and file pages. > * > * The amount of pressure we put on each LRU is inversely > * proportional to the cost of reclaiming each list, as > * determined by the share of pages that are refaulting, times > * the relative IO cost of bringing back a swapped out > * anonymous page vs reloading a filesystem page (swappiness). > * > * Although we limit that influence to ensure no list gets > * left behind completely: at least a third of the pressure is > * applied, before swappiness. > * > * With swappiness at 100, anon and file have equal IO cost. > */ > total_cost = sc->anon_cost + sc->file_cost; > anon_cost = total_cost + sc->anon_cost; > file_cost = total_cost + sc->file_cost; > total_cost = anon_cost + file_cost; > > ap = swappiness * (total_cost + 1); > ap /= anon_cost + 1; > > fp = (200 - swappiness) * (total_cost + 1); > fp /= file_cost + 1; > > So swappiness still means the same it did 15 years ago. We haven't > changed the default swappiness setting, and we haven't broken any > existing swappiness configurations through VM changes in that time. > > There are a few scenarios where swappiness doesn't apply: > > - No swap. Oh well, that seems reasonable. > > - Priority=0. This applies to near-OOM situations where the MM system > tries to save itself. This isn't a range in which proactive > reclaimers (should) operate. > > - sc->file_is_tiny. This doesn't apply to cgroup reclaim and thus > proactive reclaim. > > - sc->cache_trim_mode. This implements clean cache dropbehind, and > applies in the presence of large, non-refaulting inactive cache. The > assumption there is that this data is reclaimable without involving > IO to evict, and without the expectation of refault IO in the > future. Without IO involvement, the relative IO cost isn't a > factor. This will back off when refaults are observed, and the IO > cost setting is then taken into account again as expected. > > If you consider swappiness to mean "reclaim what I ask you to", then > this would override that, yes. But in the definition of relative IO > cost, this decision making is permissible. > > Note that this applies to the global swappiness setting as well, and > nobody has complained about it. > > So I wouldn't say it's merely a reclaim hint. It controls a very > concrete and influential factor in VM decision making. And since the > global swappiness is long-established ABI, I don't expect its meaning > to change significantly any time soon. Are you saying the edge case behavior of global swappiness and the user provided swappiness through memory.reclaim should remain same?