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 6C059C4167B for ; Tue, 5 Dec 2023 16:19:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D46E56B0080; Tue, 5 Dec 2023 11:19:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CCF896B0081; Tue, 5 Dec 2023 11:19:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B70EA6B0082; Tue, 5 Dec 2023 11:19:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A350D6B0080 for ; Tue, 5 Dec 2023 11:19:34 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7460F1C0281 for ; Tue, 5 Dec 2023 16:19:34 +0000 (UTC) X-FDA: 81533275068.22.5451887 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by imf09.hostedemail.com (Postfix) with ESMTP id 30CE1140026 for ; Tue, 5 Dec 2023 16:19:32 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=m09ineLY; spf=pass (imf09.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.167.180 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=1701793172; 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=cOwZEVf0hmkZ/l+HRKkvqqzx2g2Yp/f9J4vlDNBGiHU=; b=dBeOZj1YCv9xF7ZpA58j7bzSCQPlwOaqthbn00IpdOLHuJ4LsyvGDT0ny65CqSJ0ZeyWd2 RrpRm7SeZ1EEzr1GOK6rd6DG2gyuXEvqbGyve3Mb0jnJYUaF8UhH2aOeHedbeJ50HIdYvz lY+kD/cYXmv9lMEZETUGCCLN5P/UJzs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701793172; a=rsa-sha256; cv=none; b=iMOaZKhaqlfWjo7f0J19mrf2YaVHsARzH1bgobezqwiplHf41DtkFmt/tlNl8pSwpnvAef q7EcxPDL8TyCIoxBOAaUE7f0OQThPFMAgCBuLFO138PnUi2aad/aO1WOJ+iVDaV/5dA88q /8mAL0Zm4nEnxUxw/W26Bq93a2fHv3g= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=m09ineLY; spf=pass (imf09.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.167.180 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-oi1-f180.google.com with SMTP id 5614622812f47-3b837d974ecso3665081b6e.2 for ; Tue, 05 Dec 2023 08:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1701793171; x=1702397971; 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=cOwZEVf0hmkZ/l+HRKkvqqzx2g2Yp/f9J4vlDNBGiHU=; b=m09ineLY++S3f1EqIm50rKUrse6UEoZtLkR8jKdJuKDj5BlzpcSY/7vQTLVtgP/yIK EB1RAtLzs0oQmRa5bU1U+gIwlbo22qvjnz36r8IE81aL2xPpowBDbkJjvKZwpW4dEGMb Ud5huxMuzTcduJunEjZIbGlZoTAPepGStDDQ+q50wvM71yiDKRnjujdErlKllnMHMHQ/ V2xfIh1yMDG4WaroYAP4/9s1CQWNRDeEvhN+qajJ2VSiqQDjAcsOILq8lQEQvk5vghyJ 6rRoIugR7LqpdrKyXg+pq+t9NMZuxOgUIHz5gwQ7CWZ9VoIzzFXYEK8C1vbcPLgwyMk6 h5Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701793171; x=1702397971; 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=cOwZEVf0hmkZ/l+HRKkvqqzx2g2Yp/f9J4vlDNBGiHU=; b=YCZcIHhITwW+X/g2/ueN06H8VRYme3nuT+7Rgp8y06OtQ7nfx7MtMpraxAp9zdubiJ WFvOjLhuSLcvRBR9rHmIcDtEM4xjoibIUsOgdyNLEuJ1NRTAtaAgrHlyqqQ9JtA7enVO VO4mivb74dUPEVwj35W4Mj8wUUKNworCJZHTc1pA3Ct+y2eYv0Tr2bh50wM+6onI8D2h JCJHzWEaob+U9FDB4OmUIEpjgQ0Q5L9IZ3vjOagWCRmZTq0HaM8ngM/rq2wObb3TUvSs zJvHtCM1GNpW9VuvDVkiLsVMFzRNzNLfIIwOb322WVgo/ZijyIzf8YHt26yYIzJifojx Vh2w== X-Gm-Message-State: AOJu0Yy4zGvpQFxb0qdRoCxIfRo+0aumhVD6nCWda5KfhC0JO2ZXKwfw 4tkLMqkSIai7ueTBF7Rkkr6lww== X-Google-Smtp-Source: AGHT+IF0szzPb51TMNvPFceb886yewCVCDgejwmhkzQ/VpGpcexkajnRa+SXBlHruOBwpSWcysfvHA== X-Received: by 2002:a05:6808:b0f:b0:3b8:b063:ae0f with SMTP id s15-20020a0568080b0f00b003b8b063ae0fmr6846455oij.108.1701793171128; Tue, 05 Dec 2023 08:19:31 -0800 (PST) Received: from localhost (2603-7000-0c01-2716-da5e-d3ff-fee7-26e7.res6.spectrum.com. [2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id c8-20020a05620a164800b0077d78c5b575sm5197904qko.111.2023.12.05.08.19.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 08:19:30 -0800 (PST) Date: Tue, 5 Dec 2023 11:19:29 -0500 From: Johannes Weiner To: Michal Hocko Cc: Dan Schatzberg , Roman Gushchin , Yosry Ahmed , Huan Yang , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , Kefeng Wang , Peter Xu , "Vishal Moola (Oracle)" , Yue Zhao , Hugh Dickins Subject: Re: [PATCH 0/1] Add swappiness argument to memory.reclaim Message-ID: <20231205161929.GA99931@cmpxchg.org> References: <20231130153658.527556-1-schatzberg.dan@gmail.com> <20231130165642.GA386439@cmpxchg.org> <20231201170955.GA694615@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: a9eiiaqgj6yhpnxo79tx6hdp13n4xs4r X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 30CE1140026 X-Rspam-User: X-HE-Tag: 1701793172-10186 X-HE-Meta: U2FsdGVkX1/mFRRmFAWs0lR3cI94OdwQEmexDS86SJGPAWCBCuk+jKgZgIgJy2zJvTDxxQDp6PdUZD7YMt6QOAX7nOkboWEGjqnYiPWYSRfnVwQ6micDw1zNCaI8fomIqrI1wAdJuTrvPzW70gL714td0JtrsiS3qIEcX8XFz/WHvzxULZpCqjv3HJgpR9rhY7kCjCt6m5/2Hjf5Zh+ZcB2wGqPrlSIRcWipb6SWvszPsw7Ox79yuALQXb57OLNjBqHQuBGjN5zPlYhBeJwZCpHwSzQLY6vkrfVRlgF6OO7ZHJoeCAiwG1ZdoHVegVPpL3bsHymWR8tXDhet+oBzZi9kbI8u6aVlKAjv75/3s5nV1m5k4kGnBHMtj5wBdWGOOuz+wBfFG47/m0uoz83Dl1J8f1jqvwWUk52ukcKsElgIQZ37O9T4tIo3/vgMre9xsaDRFRyo1G7zbpilTaBwF0GSryZ0cD3dlRvgOjrq9uNdPKksW+I7kyjU1WOZxmUBjH1umeaxeDbC/q2uJbRmA11cP1gNtHsg3xbwbzD32Wo28tEgX3g7EQiOhiLrTx/b8p2ZP9J21qtKANsR7xHGNJiDTBrlnaq2KEH089hI0kBTjlFmUghSwvODOLuTKBr0rhls/ts5cJK4b3LGHXRNR4TQNSfgydlkxwfbq3V4TK59nkuBV1BN0ZWhMM8fqNMKAvLych9tMF4Y087LkQr2KezH8MbEHV0OXth+dWI+ppF4Up1OvVOsMhrXoXKBGFDvRFH5wmWRVQASJUafwfnQl9LOGUt5wwvwnXON0jukYT1jm0HXzshGimr0SMgKMB/+7EoGm4SOfchd6PLLE0OPQqdRoAu14773ooL26JZU/tAO/PtiFPYqlunK2/HSfJjcAZwXXXCIf3Akv9Iuz38iXbwfMgdd2yOkkNd4aE+bVnZlFabzGpmikgoSH/tm6mvfzNLgRMJAFMAHyTYz4EA gBfgkVzW L00bOYUv1yWeAC/ahhNArwiOzC/5wdSL1U62q3e12wD4WGAFkF41tMnOrK0fUeGGNHq/brif8Li8SAWkJSgPA1iP98u972o+OgKOYsRq1ILCsFr83WJPLSFi39MICUhY+nO9YLFWQZr1AlLATSiR9z0KlMg4yB0z1goo11OJmBQi1hiWazrCTKkV5WmkW+TMbbRCg22KGe1SjUyvD/1QrKkcP9GBGv1Joy96zH0g4fX0C2KVk7uR04VIver3HUOx4nhd+gnh77XUNv+jh5Lhb5pJZeZ/h2U+bfs57Xrsi3kAD3VilzkLPDawV1rJUyT0+bEtI9p5jd+odcPtfcob0jglqACVWuqEVwZ5VJk33Kz42CSjXzJYf6/Kwt7ubdL68PGgGjq9a24/8sR8oLsmT4piZ1+Wti11EsbIMfP0onUp1BAuzaQ/3hOPLr5qu6qg64n/XKorEjUnxxtdiyAnENsDzIqnHVyDwqlNgm8Qwn1XcO80nQ8zRxo7duxG7sWpy1U+vAbCI9YYjEJA= 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 Mon, Dec 04, 2023 at 04:23:47PM +0100, Michal Hocko wrote: > On Fri 01-12-23 12:09:55, Johannes Weiner wrote: > > On Fri, Dec 01, 2023 at 10:33:01AM +0100, Michal Hocko wrote: > > > On Thu 30-11-23 11:56:42, Johannes Weiner wrote: > > > [...] > > > > 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. > > > > > > As I've said I am more worried about potential future changes which > > > would modify existing, reduce or add more corner cases which would be > > > seen as a change of behavior from the user space POV. That means that we > > > would have to be really explicit about the fact that the reclaim is free > > > to override the swappiness provided by user. So essentially a best > > > effort interface without any actual guarantees. That surely makes it > > > harder to use. Is it still useable? > > > > But it's not free to override the setting as it pleases. I wrote a > > detailed list of the current exceptions, and why the user wouldn't > > have strong expectations of swappiness being respected in those > > cases. Having reasonable limitations is not the same as everything > > being up for grabs. > > Well, I was not suggesting that future changes would be intentionally > breaking swappiness. But look at the history, we've had times when > swappiness was ignored most of the time due to heavy page cache bias. > Now it is really hard to assume future reclaim changes but I can easily > imagine that IO refault cost to balance file vs. anon lrus would be in > future reclaim improvements and extensions. That's a possibility, but it would be an explicit *replacement* of the swappiness setting. Since swappiness is already exposed in more than one way (global, cgroup1), truly overriding it would need to be opt-in. We could only remove the heavy page cache bias without a switch because it didn't actually break user expectations. In fact it followed them more closely, since previously with a swappiness=60 the kernel might not swap at all even with a heavily thrashing cache. The thing Linus keeps stressing is not that we cannot change behavior, but that we cannot break (reasonable) existing setups. So we can make improvements as long as we don't violate general user expectations or generate IO patterns that are completely contradictory to the setting. > > Again, the swappiness setting is ABI, and people would definitely > > complain if we ignored their request in an unexpected situation and > > regressed their workloads. > > > > I'm not against documenting the exceptions and limitations. Not just > > for proactive reclaim, but for swappiness in general. But I don't > > think it's fair to say that there are NO rules and NO userspace > > contract around this parameter (and I'm the one who wrote most of the > > balancing code that implements the swappiness control). > > Right, but the behavior might change considerably between different > kernel versions and that is something to be really careful about. One > think I would really like to avoid is to provide any guarantee that > swappiness X and nr_to_reclaim has an exact anon/file pages reclaimed > or this is a regression because $VER-1 behaved that way. There might be > very ligitimate reasons to use different heuristics in the memory > reclaim. Yes, it shouldn't mean any more than the global swappiness means. > Another option would be drop any heuristics when swappiness is provided > for the memory.reclaim interface which would be much more predictable > but it would also diverge from the normal reclaim and that is quite bad > IMHO. I would prefer to keep the semantics for global/reactive and proactive reclaim the same. Making an existing tunable available in cgroup2 is much lower risk than providing something new and different under the same name.