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 C40EAD1BDE0 for ; Mon, 4 Nov 2024 18:48:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F24D6B009F; Mon, 4 Nov 2024 13:48:48 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A3966B00A0; Mon, 4 Nov 2024 13:48:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 069496B00A1; Mon, 4 Nov 2024 13:48:47 -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 DD2336B009F for ; Mon, 4 Nov 2024 13:48:47 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 656FD40309 for ; Mon, 4 Nov 2024 18:48:47 +0000 (UTC) X-FDA: 82749297330.09.AF84F6D Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf10.hostedemail.com (Postfix) with ESMTP id 07F14C0009 for ; Mon, 4 Nov 2024 18:48:30 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eeuT2FJi; spf=pass (imf10.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730745904; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=q1grBaj9tmVZjme5LsYUeCJ8WPXc1t/fLGncF4nFHtc=; b=S+OJMXffM7XZCsE24+bpj55nX5pgAAZs9PNp4ElQzQg19+4qd+XTyPPOwbofK426wOK8hf ta7f4NMtE6R+AZbtj2iane4dxTSlcYIQ66uDRlJRMWcUVxUaAnDo1SC94f34aJVGWMqxJN qQ0/+24S9yqnJPZ4wmzRN0KZxjykp0c= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eeuT2FJi; spf=pass (imf10.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730745904; a=rsa-sha256; cv=none; b=xzzAvc5b17fnNhw3U4bU3YO0b+Ib0cGmzqZOnnsL0/34G+RpxLZd0aJZvgheWDbQU5aSwt 3bIyyDOA4HQEFzVDfJ7TtMwXD5EssonJ/bua1HOrVOtpDS2m2iBm4TxLdE+LbMYUwJbbPB v8aVrvhceGCuM9L7GMiuxIeB3m/BVsw= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a9abe139088so700166066b.1 for ; Mon, 04 Nov 2024 10:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730746124; x=1731350924; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=q1grBaj9tmVZjme5LsYUeCJ8WPXc1t/fLGncF4nFHtc=; b=eeuT2FJiseFI2seiMGHCduwloxdCHYBlcO9IX8jc47FWBYanEu+ZClTqER5yh0l7uq Z0ggD0l6HjSDo25d40QjHt3HCX7mQwWEYZMSp847vFTUoxIUScS8SzetnX1sHksPxzeP b7Qt6Eu5nGqLTcx3ZZdQkM2gErkxl8W8od+wkQMmXMpRw0OGNBogxX3EiwGcxRysxJoe RqCJgjgeoFe/hzjsiEyt6AoTsFGGR9nusIsNrHPSgr+fYjjXkZkZRgsD0wImDpY4fiSj AQcI918hquLqBQ9TN4f2xR5D70IjJmfIqgvTgiC52dZKEU+pi8rmIGWCmYvDdjzCGv4e kmbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730746124; x=1731350924; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=q1grBaj9tmVZjme5LsYUeCJ8WPXc1t/fLGncF4nFHtc=; b=LHttm6PLE2nGa24l5Jh8MVtaoslZDWDPzpclX3g4KORTK9ZkXUblbV6ADTQ0aKh+E1 TUwengW93sDM4Tm3e3INpQQICEsyPs1kjakTfy+yRGkUoxtO+oDFQmGZbLnJtVC8+eR2 BEWRP2rEZ6gX8kySSkhCX0coQ5LHBx2iwOl5dufoKbW3OcMn/LSBgojRnixbEbEBU+ea bfbzMFEvUmFkHjPWuGgKRZ4O0mFfru5/vtSrVZoYOisqZEaO+mEyGMFP5C6faeMOWyp4 i5xadzCwVUgjzYxJi+jYC2kyf39H7DPJzu4ZinVChCRIZ2Y6YqD+WP3OfobrMbb7bYge ex6A== X-Forwarded-Encrypted: i=1; AJvYcCVrbYxznYCLZwIvseofOGCI/sw1PJjxOgsE0rH3o5aUBJ/WrgqY1szx0zI6zuXbCdxBffIZZIyckg==@kvack.org X-Gm-Message-State: AOJu0YxE3wmLeanx911NSvSfEcL/DT5pz2/0wgiwNDxqW+kmmF8E9vLQ PbhFUe5ZeR4jdmYQtp+rLb75kdZlyJAi2asozL/l35rUWPRSDYzy X-Google-Smtp-Source: AGHT+IHs3NQ88ui7RfqRgWZ4U1BVrC8/PJErJCqRk5UTyyA8xYwSVnWZom1uOI53L5D3IDTjbfaZEQ== X-Received: by 2002:a17:907:8689:b0:a9a:188f:efd9 with SMTP id a640c23a62f3a-a9de5edcfdcmr3472433066b.29.1730746123361; Mon, 04 Nov 2024 10:48:43 -0800 (PST) Received: from ?IPV6:2a03:83e0:1126:4:eb:d0d0:c7fd:c82c? ([2620:10d:c092:500::5:76d9]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9eb17d7328sm16184766b.129.2024.11.04.10.48.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Nov 2024 10:48:42 -0800 (PST) Message-ID: <3ac28c1a-44d4-4b10-966e-0907df716da0@gmail.com> Date: Mon, 4 Nov 2024 18:48:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] mm: count zeromap read and set for swapout and swapin To: David Hildenbrand , Johannes Weiner Cc: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Chengming Zhou , Yosry Ahmed , Nhat Pham , Hugh Dickins , Matthew Wilcox , Shakeel Butt , Andi Kleen , Baolin Wang , Chris Li , "Huang, Ying" , Kairui Song , Ryan Roberts References: <20241102101240.35072-1-21cnbao@gmail.com> <20241104163402.GA810664@cmpxchg.org> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 07F14C0009 X-Stat-Signature: htgq51x66kisxu1ykfiy81x7nqcxdd6y X-Rspam-User: X-HE-Tag: 1730746110-206705 X-HE-Meta: U2FsdGVkX192IcNdn8oCW7UCZ2TKcksQ/CsMoIei7pZYpj9FrCMKxZRA5U6Nh4QKdc+n1wPFuh+0V/ijtXV0jIXMVPVczj/Cq9r5qC+BJbZBID8/7ppELlae82l2sPFUqFWaP7ScDnnYpsyp1xN4v/jDHswM+L0kRIVXlfMCq7XoBCsE6p3b2LAusvJB9x3rxD7j02nWomHeXVLwMVNZY39+VlXVCV6xM2J4xS0ThyFCrABZ8qd4wFWkYtWGl2KuW+M+dK/x9ZTlY/WbVMeVtY8Rbr2l75au6VTo0WlJ5zqh11qQd1F69LQZeWmCXaaH/osy7p6pzAAyRJc4E+qyyAidDNZOS3bzSECdAWjx6FBoGphaplqxHe7exDDSCR+ZbBz+ulcfuq3987Qd+fBUoMInnhjhIzlc+uO8fMX0/u8ia+yg6nyUJ3ZvMVKbbAsusYdCnXJ+0qpvXfydSKxX21/u0vdwxaujuO7C7HHTpgznzGNgAxByGQUetUzIhfxp7A11UnEBnqwyl8JptSxdw3jVsEa3fsFxouUvDzkmqa2SVZLmoNNmQXrC9/rdIUo7J4btXWXOlyp2DmFRF/4/KAhvziesmm0/edTDdAKbXhFR0ivm7qPmUpi9NmADGvpSUlnYyIXFkO3mli7l/JJ51VlyC/c6/CbndatsbzYCtxgnFomEXiSiyAXEJBwtMN2A6QHQV4RWz3I8HXSIPGRllrz96Bu9nEbZjSUIKQQUa9fu6NTzGvlCJ6sIUwDlX1CD7d1sE4K2WWS5GykkLFo0trWrQdnJ8sEMnxN0r3Zx4uT/1WwaBRZFEEzLzKN2NdLnV4rwjPwbcNt79O7rlwKmEr+univlgNYZwI3AjmGGygGkuVm9LxD7STv9l4hOOptgFgR+YC25BFJj7VBFofLX0sDUdPVksPzOSw+wmrZBtrYsePEf9SBKkJX+O6LZ/Uk9pKO4zgUe/28lZAkrhFM lYbxTN7R n1c1FRAOyqYtX5gd5o+7vc/SwY4Y6QGmyG1o/4+L2Z75lT6eB7z+2ci3QOQCXkUswRxg9N43wzVEC1yKjpiGuTyGoMHFXpURnLE05eQ40KOeweOo0SOisG2qXfigC5ymx8l3vIeBbIjGkheABMyAFZyRqpMzlD/v315aN2m1KsGmjIcctmLeo+/brolY3Bh9RGqKDp4TnW1oWrUR4zElHGLlUKtM1fi8PU6kpDg9NXKyk2kDbaf3qn4typRuFkt9N76vyRBjFhxDCe5d0yobjqA76bRBZ+FiULq2ITiYtyektZz88cYePOzhQJ98ueyYBU+Us3+yRC2f8tGCz6NsI7wHHlmI4eBDjtvq4Rr2q7hS26IjNVMUdpj7RWnI4ZHisP2J2qQS986276EbItnmHBCyH3c+jUhlHqPHuiXOkTfjLFhbFc4PtAYu47+ryR6mCbB0FAKvttagmx3M2vcBKTHWTfCmdH2gsJKY4ceKX+NXbWCno/Olgfqj8LA== 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 04/11/2024 17:10, David Hildenbrand wrote: > On 04.11.24 17:34, Johannes Weiner wrote: >> On Mon, Nov 04, 2024 at 01:42:08PM +0100, David Hildenbrand wrote: >>> On 02.11.24 11:12, Barry Song wrote: >>>> @@ -1599,6 +1599,16 @@ The following nested keys are defined. >>>>          pglazyfreed (npn) >>>>            Amount of reclaimed lazyfree pages >>>>    +      swpin_zero >>>> +        Number of pages moved into memory with zero content, meaning no >>>> +        copy exists in the backend swapfile, allowing swap-in to avoid >>>> +        I/O read overhead. >>>> + >>>> +      swpout_zero >>>> +        Number of pages moved out of memory with zero content, meaning no >>>> +        copy is needed in the backend swapfile, allowing swap-out to avoid >>>> +        I/O write overhead. >>> >>> Hm, can make it a bit clearer that this is a pure optimization and refer >>> to the other counters? >>> >>> swpin_zero >>>     Portion of "pswpin" pages for which I/O was optimized out >>>     because the page content was detected to be zero during swapout. >> >> AFAICS the zeropages currently don't show up in pswpin/pswpout, so >> these are independent counters, not subsets. > > Ah. now I understand the problem. The whole "move out of memory" "move into memory" here is quite confusing TBH. We're not moving anything, we're optimizing out the move completely ... yes, you could call it compression (below). > >> >> I'm leaning towards Barry's side on the fixes tag. > > I think the documentation when to use the Fixes: tag is pretty clear. > > Introducing new counters can hardly be considered a bugfix. Missing to adjust some counters that *existing tools* would know/use might be  IMO (below). > >>  When zswap handled >> the same-filled pages, we would count them in zswpin/out. From a user >> POV, especially one using zswap, the behavior didn't change, but the >> counts giving insight into this (potentially significant) VM activity >> disappeared. This is arguably a regression. >> >> swpout_zero >>>     Portion of "pswout" pages for which I/O was optimized out >>>     because the page content was detected to be zero. >> >> Are we sure we want to commit to the "zero" in the name here? Until >> very recently, zswap optimized all same-filled pages. It's possible >> somebody might want to bring that back down the line. > > Agreed. > >> >> In reference to the above, I'd actually prefer putting them back into >> zswpin/zswpout. Sure, they're not handled by zswap.c proper, but this >> is arguably just an implementation detail; from a user POV this is >> still just (a form of) compression in lieu of IO to the swap backend. >> >> IMO there is no need for coming up with a separate category. Just add >> them to zswpin/zswpout and remove the CONFIG_ZSWAP guards from them? > hmm, I actually don't like the idea of using zswpin/zswpout. Its a bit confusing if zswap is disabled and zswap counters are incrementing? Also, it means that when zswap is enabled, you won't be able to distinguish between zswap and zeropage optimization. > Would work for me, although it might be a bit confusing if no zswap is configured. Maybe just needs to be documented. >