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 7D5D3C10DCE for ; Mon, 4 Dec 2023 15:23:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3B966B026F; Mon, 4 Dec 2023 10:23:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DC46D6B0270; Mon, 4 Dec 2023 10:23:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8BAC6B0289; Mon, 4 Dec 2023 10:23: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 B6ED86B026F for ; Mon, 4 Dec 2023 10:23:52 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8F5C51C0599 for ; Mon, 4 Dec 2023 15:23:52 +0000 (UTC) X-FDA: 81529505904.11.26FE765 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf19.hostedemail.com (Postfix) with ESMTP id 51B051A0007 for ; Mon, 4 Dec 2023 15:23:50 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="Qx435/8a"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1701703430; 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=MSfuO+OQqjKaU4tpQqlga4ZTtzNlctSschnkLgDRivg=; b=kYuTstEE3TDg7plWtQr6Vmis12lm04JrdIAviwk4F3NrSGv2HrXpuzfweNqDVf7vz5T7AB gsy0b1Rv5UpEhH26Erf+Sp2bCoNeZOfdAVAkkkkVRzDMPZzTirJp6SGEyVcWfQ2HrVzAVy +AnJrv5yezqffEWx51wC5vWiYPgbKmg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="Qx435/8a"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701703430; a=rsa-sha256; cv=none; b=huxnEMMdbnVhjNM2W/Hl9eFFjbLKdIFSwCdM5mOY1DwWMa5OwWwBbmk0NVyVI8Yj79lJur Lb6ioGR43TY7lLwQhNlvN1fGhb/3isOn9rKPZKNtQ1mING5qsCvsv6N24Lc8j0y60B4bwt OU/02yYNn2Raf9yyAIqP/ySfPZ6umq0= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 6BC34220D8; Mon, 4 Dec 2023 15:23:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1701703428; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MSfuO+OQqjKaU4tpQqlga4ZTtzNlctSschnkLgDRivg=; b=Qx435/8aK+ZnOG7Hv2GM0J7AuyqsexLTDkphaopr7hyK/MeSQAylHN/RuGGYI0Te8D27OP TkCVr4PXQ502a7kEIJzauKJeTbOclWyNnnLMWI36eLvPhBGvBOCtJ9Z0C5BJZs6lf2EcWG FPRBE2s7R4YBMPA2g78KYOvPnbo+vFw= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 427FA1398A; Mon, 4 Dec 2023 15:23:48 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id feo9DATvbWUMUgAAD6G6ig (envelope-from ); Mon, 04 Dec 2023 15:23:48 +0000 Date: Mon, 4 Dec 2023 16:23:47 +0100 From: Michal Hocko To: Johannes Weiner 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: 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: <20231201170955.GA694615@cmpxchg.org> X-Rspamd-Queue-Id: 51B051A0007 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5m3ikkp1tdaq3x8yu1pa948jsbx833fn X-HE-Tag: 1701703430-15701 X-HE-Meta: U2FsdGVkX18V8ev8MdUoxQ4gT7biUmnx1/tNzAccCxhLX/tYIKFtPTVxyOLMTSsgaoshkqhXjesFeaDqafSIZ5AHMA/YEX9gNFvVmH9Az/gzAs7EfMSJUCmFHjTmQPs/c36BaqXEzu5p//DMreYSDRaqJMbIz0oLIgjP7mLl9m9SOk7Y8O7/Lcvd0yx6jV5ae40EmirLMWciB4q6HCT3T/l19HMr5KaRCfsxoJyNc8EucFFEsYckI7CytoLceWHoDt4dWgGxunPTtLSq/e0FEVQEVctNc6NgpDY9unrAbX8T0oKnLQU34F+oEZ0fXcNUiCVJFT1Pv+9w5MjE72VpJEvTJPSatVOR+PD6cs3K4LR4JYDFxy90ST2b9CECvjYBsjpGjspyoRmj+DIuxPEtdS190B9nAt49vWIGOz/TJ+B8LJUJtAOyScHLx2hzc47TJcedh74vz8yZmP4d4L5Vlz3+ca+U+nDl0vnAT0w2Pny+2O4PUJ05b5mHx1NmAfGuIBWr87G4A8aK1wgk3BUSrzZjhi0Oh2SumfsL2NpcdPZZkuDZGQRmRMx9DJYjCPYWOEBqEVal2SOy+QH8nGf7h451Y5YIjVL8YcMuo6Gg1I4sv+KAgF1R1nPK33+mCyhmJq/uovew3dQgJ7KnoUnz2bdWR2aO+w7gUAUW5YG3TDjELSUV/iROTa42/bRMVM6wsAgusG9xfzTGm5pULO4qkGntF27JZrFsSeoDoabY7XO1ouPRp+Ms96UeSepSwauj7JhCuRLFFViiC3NXyrQ+X/b4/0hSZeKmeyi8mxmOtVbZK0Qak0oMNslvdcCyNOLUZhO+zYk9nMPKbM9Vxodv9ABAgpHUZJbLf7ENfZjnDV4XX0c1yugbkt7HdY5YJOPujXloDt+e+RY5gdkZHY4kQqXAyN8TR0p0VH9QvunVuIL2bQBltUZ8MvbsYUQkKFMrlczAHPMk6HySwAE8X+i jvJv3Lcj f581CVVmqsIoRoMzriJLUYjy4wiRb4+trVZQP7latUl8KG2NpOaPI2l5SageEL9DhQX17Y5R6izD2ijqt2HBuJmUQytmFLj545qqye0S2YtWZqrGrxfXqKU4gs/YZwMHW29UftPiW95EF6h+6Iz6aqMmS59k0wey0ExJhpjhrqqDb+zc27WhZ6qS36sNwv3xmqJFKj5QNcMSDtY64GGP59HiFIriauMTQ2mxAYKrNyr/5bdQxRPICb5gHX7e4tf2NIaa9kxESHrMqvilkjG3N0mHzRPkWvrMM+267 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 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. > 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. 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. -- Michal Hocko SUSE Labs