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 A05ADC0218C for ; Mon, 27 Jan 2025 06:31:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE38128011B; Mon, 27 Jan 2025 01:31:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A934F280119; Mon, 27 Jan 2025 01:31:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9828A28011B; Mon, 27 Jan 2025 01:31:21 -0500 (EST) 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 7AE3D280119 for ; Mon, 27 Jan 2025 01:31:21 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id BE82FB3B94 for ; Mon, 27 Jan 2025 06:31:20 +0000 (UTC) X-FDA: 83052259920.18.8555D9B Received: from out-177.mta1.migadu.com (out-177.mta1.migadu.com [95.215.58.177]) by imf01.hostedemail.com (Postfix) with ESMTP id C7C214000F for ; Mon, 27 Jan 2025 06:31:18 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=w98TqN4H; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737959479; a=rsa-sha256; cv=none; b=MKARiRlPF192Ro9Q8OFrb9542vBb8QLSk/3qIOJWCSuautNs+xxsHDRyFS/j7oIW/TkiTx NdaPp4YvW430uRusfnIdUN3bsNyA2gyv0CQkOnTo66XpGY84U+bt46wku6A4WgaBqWI6yr gVz6SA/jc9dPM1lwgckscmxACqpwF40= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=w98TqN4H; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf01.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737959479; 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=+7YZFYRpMp8b2yHITL2IcUj9ucb1cofXsJ9DfiW8b2w=; b=szmJ11q1807lJv1eT+gLp/l/T1ErvWDzhBjCChcTleaWlCVhmoXnMekH8jHtYQzEZajD07 LuABsqLTYzHdIV8p2D2hJx5V49uQdxrWMo+Z6R7AOYSgNncPVCHpev0K/eR+JPWC8soZLG SDec1Ip67i+zmioEhmX20I/TV8iGvHM= Date: Sun, 26 Jan 2025 22:31:04 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1737959476; h=from:from:reply-to:subject:subject: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=+7YZFYRpMp8b2yHITL2IcUj9ucb1cofXsJ9DfiW8b2w=; b=w98TqN4H61A4WW0VPHdSG197xC7RT6jgVIYyLkOdgfvqnLxbJE75yuoqp3PvP/w9x7igWR jwrUo/C97IZioE+MOIS9k0fYYyhn7A/zWFfaS5vKwutY+9MRA6s8t1pl7ZPr0rmdhWMvCl UHWShsgNX6qKnp+Vjnf2y1fJPVmZjs4= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Johannes Weiner , Kairui Song , Chris Li Cc: Andrew Morton , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: memcontrol: move memsw charge callbacks to v1 Message-ID: References: <20250124054132.45643-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250124054132.45643-1-hannes@cmpxchg.org> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: C7C214000F X-Rspamd-Server: rspam10 X-Stat-Signature: 51hqhhqir7oie5epjuuqqfej7w9n9qeq X-HE-Tag: 1737959478-314021 X-HE-Meta: U2FsdGVkX18suyA00Wuxnv6rsbNEQrDq7IY5PzwVWiEWae6CWBowiz1I2BnZzCvkjCKUzqCGwDmW2+I1WNtKJFhtGtx015uj2DQwkovH72YXrIaTp/txnqFp7vEx5jTW7DNCCUzCVeCjEylsf870FHSqaegIwOkZLuPExCNNLFdqkwrITIwkZDS7gDbNV52I38IbUvYOYwzhAkITAjCpPKRc4FWpIOO+O6AmM0QtbWKxBMUt+/kIwGFuHJshZVy2KWUzXomcWhsWApufP4yKUE51Os7uNs1uW+og6ObWG814kwZDu0clkehx2ujNwa4NS7XgK9H45ZILoKqUdAzv+Q5HTqQPG3o6gEOasyJ+motI98Zf884YNi9GaGeWKRIThlvxWJBuOXIYYw78+0Ga9EWWX67ZJ5Bc+ak+8acSMGzo6bOBogx6TgjZ/jh8krwt+FtScfnzBl6wS2h2PhIUdel4lUNkLMyLBxGyUipDzTtBsCAynFy/fivzRaosbDQTDpBgZZ6M+RdzAUV93XYekgqOkWhhmx2V3L3AAB/IkBZUexcCQdy9dxTZOD1c2hpTMNPFyberEDTRVtY0tsTC9w3b021yQiqKIXpjnSbir9p2wkaourIBSuYeMltwykRmWdvg02FkkSjEFmZuLiU0xx1Nz06D/zIV8Urd1SW8Q+2K8KXwB02UlURRwW6xn6WSTl4ZNH+XKX5AkL73ps36ZOjiLmuCgqa5PaAhHujm0shduQ2kQ/uZCGjq0E0tA1lVBN0lf+moKCOjkhSbJo7YaaawtMkFFk/97+u41AADs4rwHDvK4DeCS2zMXb+jOrJS3ea7ngKH/n5Uwe13RrJtQiQM0iQDzEufj3zOyjGMBqiDEN9Ld/E48wiyF6nCnlA8gGPwgaAVTlNpbwJsfPrJpb720Sa4I5g/TzHMtjkbMR/C8Gt0vM65x6FWXxg5Y6NkX3nBO0YoB95PZMj7Ffq fqxqwBiU wDCNJWun/e/a9qAoTO3FI5EKz7uvC8ZKBCSMk+2yynm1cvl80Mri/UMyjnY4x1hKPcZnMG7LweZdVfTOMD1MefkqUNkYCRqP9gdbp0HeYbgktbc0G6BKdS70Hj41kdslZOt7a/bZNtDqcRk/EeHTpx5BlTE4lu2b/9yp4TRdcQ5vMnwwrH9r1BI580txe8TM4bhlFrb4JaeJHvtW2Is5iYMtYiX6k0dEgFKUlqg6czvBUXXcpsyz6ob6kQckZjLqHw7Em2d4Z/NKymsp02cH9UA5PtnM0vemH8bTM 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, Jan 24, 2025 at 12:41:32AM -0500, Johannes Weiner wrote: > The interweaving of two entirely different swap accounting strategies > has been one of the more confusing parts of the memcg code. Split out > the v1 code to clarify the implementation and a handful of callsites, > and to avoid building the v1 bits when !CONFIG_MEMCG_V1. > > text data bss dec hex filename > 39253 6446 4160 49859 c2c3 mm/memcontrol.o.old > 38877 6382 4160 49419 c10b mm/memcontrol.o > > Signed-off-by: Johannes Weiner Thanks Johannes for the patch as it is related to the topic which I think we need to make a decision on i.e. v1's swap accounting semantics in v2. I know Google and Tencent [1] are still very deeply dependent on v1's swap accounting semantics. Folks from Google and Tencent, if this topic is still relevant for you, can you please propose a LSFMM topic for this (or any other forum where we can reach a decision). [1] https://lore.kernel.org/all/CAMgjq7ARr0=OG8GQOJvzLtfdrtiwvJ19-mx1snxqmLE0Za+QCw@mail.gmail.com/