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 1BA9CD1CA0E for ; Tue, 5 Nov 2024 01:28:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A25916B0092; Mon, 4 Nov 2024 20:28:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9ADE76B0093; Mon, 4 Nov 2024 20:28:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 827656B0095; Mon, 4 Nov 2024 20:28:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 64A3E6B0092 for ; Mon, 4 Nov 2024 20:28:27 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D8CCAA0C9C for ; Tue, 5 Nov 2024 01:28:26 +0000 (UTC) X-FDA: 82750304448.09.13E8C64 Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf09.hostedemail.com (Postfix) with ESMTP id 6A9BF140008 for ; Tue, 5 Nov 2024 01:28:02 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DtVzmSqh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730770046; a=rsa-sha256; cv=none; b=0sdk3UdOnxKqk4j17VzR8b5HcBF0Y2r0bgPW6oewSH7NYvqML5Ub0juwajfylR9W2/1WWD Pk7AhRgSyFlUZk3NROBd74dqLFWgXXVjQJUi3frmXx/l3H0Bwtu2Uaw7ZfTW7JA0APHUvK JrUGgya9gJgVXZB+A35BTJRvsl85mps= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DtVzmSqh; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf09.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730770046; 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=C9lG9v/L+g7cvpfj/8Aw1HwndNdBUrPfREGehXWjQnE=; b=vfAsg9nlRCPxZwIp/I7to6ZJ8itzbFNmizSqAKHP0Ky76skMrPvfcF2ybrQSWCtRMJLYgx BnRKmcdNrtbhaflgloQLPbIuXFoxoyoVX8AwJnzRSbdYdpa+A2vyecylww3nLR196pQQk+ hd+ka8ahMndpkNg8t0dBdzfSBqkGWRA= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-5139cd3ea31so992109e0c.0 for ; Mon, 04 Nov 2024 17:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730770104; x=1731374904; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C9lG9v/L+g7cvpfj/8Aw1HwndNdBUrPfREGehXWjQnE=; b=DtVzmSqh1L9UurxySPhUoEFY0VzuIb96PeEAg0ga666A2V8nLVNQ2xjd6A02oBJEq7 D/uYejgYSdW0IhgsMVnz+hlO/Ush7RGAMX8M3PWA/F99M6LcDz8iQO79DtBSBLQYiSr/ 2N+LeSiyhiub4Vq+Tz+p/f55HtKv3/TLpjIiGJ4RGJp7xZL77dEYwKbnSvF8JGpfRqz0 y9yYDhVKMDz04lxy0sD2l9JfY7duoJiyU7XB/dDSA0l303fCWkTyyn8b4ExaewtfTIaQ f8pIIwI16Q3y46n3G/5aIYto0LwV4CaRFdWaVRYltNVK0iMCsqZWiAiHWbmxN36l431j GKXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730770104; x=1731374904; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C9lG9v/L+g7cvpfj/8Aw1HwndNdBUrPfREGehXWjQnE=; b=urN+LliVWy34OJmAq7qttc7GZHdwAHDZ4405oWkTeuTfynqTQr4FYR8L63d64EUN2V i1FVddvSU0QUkWq7q4yNpkTXEOKuZ9L8SP5GotzuCsQ0oxWAZUZL3lC8yAotiWZ7VB96 8av9uDEZYnBm41l4kGjx+4UJwwxuDk4NsDS9w6XXSoSxhIgFwzd03OXZURxxXm7PB74I TnFZjxPy1wn/xkDeYmPrVySnLDg8WshcT/a64YRD1BDhlf6mzPoNkYI0+4DWvKKyWRPL oZQWaX6m86RNtZH8e9h0hVPZoG0NJi3balsyOwQQh67e7kickwM2ankyfSZMgLMXnZSI mMPQ== X-Forwarded-Encrypted: i=1; AJvYcCWbR+Zecd2QIWinng05wzxwxhWYa7L7j5SiRftEdlwXLU3K1nDQGRiasqkKcDlE26EqdCQWP29sWA==@kvack.org X-Gm-Message-State: AOJu0YwB+xXJ6anXqjt4ngPRA19h5iVUqKRIFHvOVaXfXsY+RMsHYVeA cZqmG4Wh2sPU7gpGtj2uhIytnaqBRF2Z7iaDBDsMJhIPhHKMmaWOPpbsvKHmElaBQCIEUQYW33r wUJbzgqIBfWYP3xnv09msbmvipxg= X-Google-Smtp-Source: AGHT+IHznrBUG+lmELMTQdGn40EXjdLWD+kI5R3L09EXnEk8rZ0luEoALD8Ff7X3L8nSvvUVLl/23RtcrgE9Y4N4dEw= X-Received: by 2002:a05:6122:1793:b0:509:e7d:b7b2 with SMTP id 71dfb90a1353d-512270ca7dbmr12294320e0c.2.1730770104049; Mon, 04 Nov 2024 17:28:24 -0800 (PST) MIME-Version: 1.0 References: <20241102101240.35072-1-21cnbao@gmail.com> <20241104163402.GA810664@cmpxchg.org> <3ac28c1a-44d4-4b10-966e-0907df716da0@gmail.com> <410abcf1-d43c-4368-b217-4ff894903440@redhat.com> <79deed1a-9b0e-42e0-be2f-f0c3ef5fee11@gmail.com> In-Reply-To: <79deed1a-9b0e-42e0-be2f-f0c3ef5fee11@gmail.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 5 Nov 2024 14:28:13 +1300 Message-ID: Subject: Re: [PATCH v2] mm: count zeromap read and set for swapout and swapin To: Usama Arif Cc: David Hildenbrand , Johannes Weiner , 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 , joshua.hahnjy@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 6A9BF140008 X-Rspamd-Server: rspam01 X-Stat-Signature: bzmxmk58xygj6ozjj8tm9nksriu8cdji X-HE-Tag: 1730770082-918299 X-HE-Meta: U2FsdGVkX18L2LXIremNN0X0PmH6lbRm6OiRz7W7ni2ybXJp73rc0Z4+S+o0zQZ47CjDKNPmV6nxGLg9DRCla0+5rT+REpVBf6GsVw3V5pHaWoWbT4KajcOKLL489j1okpAsMmi5xStKUTGLRoHHL5Ii49Xzr7H1TE/PrY1WKHiJlZzaK2ruxkeoHhJH4pDc6M3oJkqZXkUYSAIpd5zY0kfZ1DL1y9XqVHePTAHr73kYKc3vMn5DTGQ/n+0akrJN2RKI+Kj8+5jdHnHRIdR/hC7w5PPRmRfu+LMm2SgcN/eQbl4DsrbnV99+HoEy/7cb5ATKxeNhiC7Cam1pxe5iqCXXyVwQr7CX+HDHv2MEOupJk5kgfp7SB/EGyWpSNRjo6A1qn3arz02a/XleevV1YdSkWtUMIEMV5HN9Nu9ndwfH9W08XWV6DI772i/UyqK3u+W/2yqNG9BFznkbcyrzP1CiK7qi0jIrrBxbZ7uf264PEgdMKAe8TT2w2n541rwNyV0QHB2ncBT5SQuHsbIrGrOKwJm7QFZLMtmz9PgNuUIBDodb0nKTsN8AMOtFCSPQklK5BajnRj6u2/8B88H8mNwJeQX/WpWF5NiF3kCpohKkSG53atfIyu80tba7ZacDq3sSmBgSpf9TpacTunm2Ds4+qxMeFAKzNnpqVVTElvDRN5JomUKdiYpmiF0gNxOqhckSeu925qw9lLFXo7mbg9pg7M5N//YJfdfodNCDVmQh/VbPRFBxQuygxX5eKYhm0eUwlcglFzeOabndpwxO8JYlqoLI/RaVXqZfXfHZVA1fQY3ufWzpBVkbPmai2BMh7rpEch2KnVjl1Fjg0r8QNqQnsfmLNnpH6myCm2i+va8E3DXTUo3CDGvqcDRbSqPBHTZ9DjyCmIsaK+3g0/fV2cN4vMOtXVIDEeGQ3xQFqSiS3mBipY+TFz0l65UtI6bB+IqNvlyLhNVY3sJMlcd 3fxCxBsz BzESYi0BLtQzIrguGyEMmUurUbcwl/EU0JsoKCQpheKXn2A+ikQUEGF9Ke9/bEzQizh7muNrmTbMkUoq5J+IIHx0xVPsXx1P/awYcGDdRlIYQhbGc54HAu1o0MKkw+wCDz59us2DAjIdue7zVROl1bg4zJ6XdbxxW6crYKuRX3oLF11jNDCBEINTNs83NHEWjsqM72IyoDP7mjurOeNnKjfNVXgBZJKzGtYwM0HAz1zJzvUhKkZsWujw8oBiplY/t42rLK0Q0+pM7wUQ1VkMbXFGlGCjRVZ7hjiDqhVwWvd5tp26xAR24PaeIWVPwZLx+euXRSw0ULstNyZnNH1SxUw8zVaujqRPVIsBzD4kbKvXLn/vkRNtbqLhKoJRFDyZI/WkheFCZ6DyN4MdlcUR9nJmb3FFrcjmYdO+b 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 Tue, Nov 5, 2024 at 10:24=E2=80=AFAM Usama Arif = wrote: > > > > On 04/11/2024 20:56, David Hildenbrand wrote: > > On 04.11.24 19:48, Usama Arif wrote: > >> > >> > >> 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, mean= ing 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, me= aning 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 swapou= t. > >>>> > >>>> 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" "mov= e into memory" here is quite confusing TBH. We're not moving anything, we'r= e 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 t= o 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 use= r > >>>> POV, especially one using zswap, the behavior didn't change, but the > >>>> counts giving insight into this (potentially significant) VM activit= y > >>>> 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 int= o > >>>> zswpin/zswpout. Sure, they're not handled by zswap.c proper, but thi= s > >>>> 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 ad= d > >>>> 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 distin= guish > >> between zswap and zeropage optimization. > > > > Does it matter? Because in the past the same would have happened, no (b= ack when this was done in zswap code)? > > > > When it was in zswap code, there was zswap_same_filled_pages stat as well= to see > how many zero-filled pages were part of zswap. (Not the same as counter, = but you > could still get a good idea about same filled page usage). > > The other thing is it affects zram as well.. > > Maybe We could have a hybrid approach? > i.e. have the zswpin/zswpout counter incremented at zero filled pages as = suggested, > but then also have a zero_swapped stat that tells how much of the zeromap= is > currently set (similar to zswapped). I still think we should keep zswap and zeromap separate. On a system without zswap, zero-page swap-in and swap-out are included in pswpin and pswpout counts. Although zram has same_page_filled, it's still treated as a block device after the swap layer. Thanks Barry