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 95B38D5B154 for ; Mon, 28 Oct 2024 20:42:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9BAD6B00A2; Mon, 28 Oct 2024 16:42:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4B9C6B00A3; Mon, 28 Oct 2024 16:42:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEBB46B00A4; Mon, 28 Oct 2024 16:42:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B08916B00A2 for ; Mon, 28 Oct 2024 16:42:21 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6190412013F for ; Mon, 28 Oct 2024 20:42:21 +0000 (UTC) X-FDA: 82724182632.08.0736B4A Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 6530940005 for ; Mon, 28 Oct 2024 20:41:49 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LWpPTPuX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.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=1730148010; a=rsa-sha256; cv=none; b=8q8sEdiEVaeHSlR0E7ya+sb85q4j4BkFR3zKHGovNo9Z/nveZHGy2IPPhodCqmpIeQd8Rj EKibJCzHZydRty9QeTi/vSMXL8CLwIZiGWGpz6vuIuMRNurm1D86U7mIwVWqflJr/nzx0d i5FxekHAtImCvy1/vuppCWjbUQOFjhM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LWpPTPuX; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.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=1730148010; 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=Su9Uon3IP8qi9BwGx8r1C6Fj3ZBnyqWd0zZelwtXyM4=; b=muvfO6afnB+7aW7Cg/RWsGJmpUv1jzHMzhOFqArGjhbRNT1XMPWKMScl+celhzIsAL2h8r 7hYR0iKoQ3ifFhDf6i37jv1ITDram0JtyU1rCsNzpbTNfjiCo4C9UEwbjZAwNaYoSGgygb e/EwKINz445FPOb4+9dkqpGJTLYDu4c= Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-50d3998923dso1598470e0c.2 for ; Mon, 28 Oct 2024 13:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730148139; x=1730752939; 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=Su9Uon3IP8qi9BwGx8r1C6Fj3ZBnyqWd0zZelwtXyM4=; b=LWpPTPuXzJO8x1Koc/6PUH80moNV6NcmL1ryhhsJAfZ79SLEh3PmxParnWL8BP7fRk kZVxRdcnvAALgPrC5o8T8yPsV0EEhHnx1yw9XL7oijZkgbYOADc+JkaNj03Na3VenXrd d/Q0GIXDzHGW0mwMR5j8cNLLqX8YMZaLwRVA7KeoGdE7K/iflmZx2M2oAkkGp7tqnSM0 toowzJgeVvUlzk9a8Tb0LevQ+APy6t1pkFUM2tf2sFQTJIvTnwF/XxWo3yXi048h0aaZ krw8vSizmLI9N/ZJsKNoDu6wA9h5i/fMdsPTH5Ef7v7oP/SF7J72/4C2cf/eTjIe3xfy omUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730148139; x=1730752939; 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=Su9Uon3IP8qi9BwGx8r1C6Fj3ZBnyqWd0zZelwtXyM4=; b=czeXz1jW7UVymherokwCPr8ZCFz/A2bRQBVvFUn5V/PDtqlSfZL0/T/p72ND2MOsL8 w9xVf207fczc81e7mgArKMU2EwpQcmbEMiOD56eTtNJJhv4lVC86Hu4vfrnCacmV99e5 MkOOpqgn083XxgjsiiFaBaFNYklYLwTTuVXKjmDQAuVFCs6ihzl99TJjd2rb4C6GilIC modKj27EKkJ/dhnEpOABCcG5CPpMACZ6R3Km5WvUEl9V2vJtEvg2DBwnnNdoYnnVcB5W EjXanVdhxKP60EzXf5l5YgSVsvsYzT+Vr/toNEgyKVTgPaLhZx9tHfLEqO1OjceYz6N6 HxdQ== X-Forwarded-Encrypted: i=1; AJvYcCWvZfepJhmlBxY4XOUAcZ2XepwUOeXuq2xDhR061XvFonvtzCEdSf24FeZv4KqauKIHdkV7RU+LvQ==@kvack.org X-Gm-Message-State: AOJu0YxF1P+1KXk+Rx1d6j0zZArhObxXZUnZjtK2+RDnlYgI7M9U2Hax 8MYcbm/dTZDgxuAkQDMaC2gBRW1L4CJOA9ipffNm/umlfRIfR7xPJYQOwbWK+l74WpICmTlkcD8 9n/KDUrz3lL2mfbNwkEpV0Ev2hZM= X-Google-Smtp-Source: AGHT+IGoNYRYCIo/u+HvnxWyA6vBF1v1euCWLj1/N7iweLOSVdq7Zprlq73XizDS0JU1v1r8KEWGkYpmTyRxWG4a2TE= X-Received: by 2002:a05:6122:3d0e:b0:507:81f0:f952 with SMTP id 71dfb90a1353d-510150e50d5mr6269655e0c.9.1730148138619; Mon, 28 Oct 2024 13:42:18 -0700 (PDT) MIME-Version: 1.0 References: <20241027011959.9226-1-21cnbao@gmail.com> <678a1e30-4962-48de-b5cb-03a1b4b9db1b@gmail.com> <6303e3c9-85d5-40f5-b265-70ecdb02d5ba@gmail.com> <64f12abd-dde3-41a4-b694-cc42784217fb@gmail.com> <882008b6-13e0-41d8-91fa-f26c585120d8@gmail.com> In-Reply-To: <882008b6-13e0-41d8-91fa-f26c585120d8@gmail.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 29 Oct 2024 04:42:07 +0800 Message-ID: Subject: Re: [PATCH RFC] mm: count zeromap read and set for swapout and swapin To: Usama Arif Cc: Yosry Ahmed , Nhat Pham , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Chengming Zhou , Johannes Weiner , David Hildenbrand , 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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 6530940005 X-Stat-Signature: f9tb9fqeou9ewpkikfu7axg5m84pau4z X-Rspam-User: X-HE-Tag: 1730148109-117136 X-HE-Meta: U2FsdGVkX1+tsu4evH8l9CIBJxEGnkV7yDHHxNPdDi/rO/iTx/+/0qjGjFdpzqgQjT16gKdVAsyqCK+oLNkXNhc1oYm7jfVl57Mnjx31IQEHHC1ZJVNw7AplDetlF+cssbTzLxDaDuGcsdzNkE0UZgW2Uc4SlqQglroRannolzRJoPyNxUJ5aJovj0Y7uZzKmEmLnd1+B9zmxIFvFvvUQFNEZ6UK7QTFPVX438XQwBiNNhdpUapnVBFZtJkPC/0tyCv/EbwBVKHKWJ65qYTcWD1WacPljTE2ZfzEsfBS8xuDvFTXzvSTCuEul0S8R8Cuo28+7zwjEdr9KPPTy0L+wdVXz3TvY0TOZsXREhcylQYto3thX+G/5E32NJFcdYVqFacVu4PKL4wYJE+tVO1eFcdZ4T8mT+a0R8nJrSdmqsugEHPyGOFl0wwfY8yMZqa4pOEvRx+o8O1GVwO8MFxnOqo6h8tpUs7iqcX/Qyr/HSWUSwrZYA09223zhXjLTm3VJE7nq7s8cPLVVT7/80I3HrlwcS9ra6uGyAjPVlf4xYBI2O3YcLz9d0Sp1l7BSiVxx/cpGBwIKbvgkLnX1VNRkvhxLTxiLE+8Idq8L8sfrvGvNh/QXfr7etilyLnalHbZMmLHexacRCbRS2pkCkgOkHtWvEsbiSkz/za1CrYnS/M2WXu0q1APUgxRyxCwZFl7UuVSDWEaimlRXae+UIqY/rq3oCoD9M/v3C87N92WbN/OCTUqtXM/sjL7/pvoJXM1tWvvJ81NohPrSyMqqA0YhGQap3JoXZfQ1hliAwjQX9iwbdQEBPtxH9mFVYTyYhnWd2LkZ15G09lolURBTxWK4+qvoFCXGzK2eelAWbzwZI67EJxZCaIvcVlZIiG+OzAAWeDUIDqIkjovSgr9/yj6nF+pKs+mbdeOY4nKDJfgz3DoEJzY/5yR9fZyHtq8nnEkX8L/8xc7mO8ORbC/j/m WKnjJLAb voS3BIZMfkuJEss6O3wGa4IiLdJlAQb49YKQabRA+j435mjuXuMJvzDnzEp3OVuEtgV5PRUgYoRzxAEFqDBtDossWHnU9hDWEbwB7jVKlk1QPc3GybEq+XC1XD5Saec70YPLo1TQ/mdUFhPjPsfOjrBIft5fJJkqFTARYscbOYxswqH9MDGNuAOrsRPWy8mbc9+RorFPvF8zQT/hqlaEsukgC2NvZJH0EtJchjPJQtwCcIvzsKPkP7OuwssLKia2zfFq3jZQyoUYQadIPFI5B5CQvzWG/Jbn+EUIE8ho2EFnowcdwj03zYsWh1t/ZMoK6pLZGZNJPR/kk4W5aLZuLiewyu7y9PajXOiDlpy/A8c9mez8NiF5dIOBrMfJojVl2E47+8gKfe7GhTahUnXekfSW3CX+Jeod3fFvd 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, Oct 29, 2024 at 4:00=E2=80=AFAM Usama Arif = wrote: > > > > On 28/10/2024 19:54, Barry Song wrote: > > On Tue, Oct 29, 2024 at 1:20=E2=80=AFAM Usama Arif wrote: > >> > >> > >> > >> On 28/10/2024 17:08, Yosry Ahmed wrote: > >>> On Mon, Oct 28, 2024 at 10:00=E2=80=AFAM Usama Arif wrote: > >>>> > >>>> > >>>> > >>>> On 28/10/2024 16:33, Nhat Pham wrote: > >>>>> On Mon, Oct 28, 2024 at 5:23=E2=80=AFAM Usama Arif wrote: > >>>>>> > >>>>>> I wonder if instead of having counters, it might be better to keep= track > >>>>>> of the number of zeropages currently stored in zeromap, similar to= how > >>>>>> zswap_same_filled_pages did it. It will be more complicated then t= his > >>>>>> patch, but would give more insight of the current state of the sys= tem. > >>>>>> > >>>>>> Joshua (in CC) was going to have a look at that. > >>>>> > >>>>> I don't think one can substitute for the other. > >>>> > >>>> Yes agreed, they have separate uses and provide different informatio= n, but > >>>> maybe wasteful to have both types of counters? They are counters so = maybe > >>>> dont consume too much resources but I think we should still think ab= out > >>>> it.. > >>> > >>> Not for or against here, but I would say that statement is debatable > >>> at best for memcg stats :) > >>> > >>> Each new counter consumes 2 longs per-memcg per-CPU (see > >>> memcg_vmstats_percpu), about 16 bytes, which is not a lot but it can > >>> quickly add up with a large number of CPUs/memcgs/stats. > >>> > >>> Also, when flushing the stats we iterate all of them to propagate > >>> updates from per-CPU counters. This is already a slowpath so adding > >>> one stat is not a big deal, but again because we iterate all stats on > >>> multiple CPUs (and sometimes on each node as well), the overall flush > >>> latency becomes a concern sometimes. > >>> > >>> All of that is not to say we shouldn't add more memcg stats, but we > >>> have to be mindful of the resources. > >> > >> Yes agreed! Plus the cost of incrementing similar counters (which ofco= urse is > >> also not much). > >> > >> Not trying to block this patch in anyway. Just think its a good point > >> to discuss here if we are ok with both types of counters. If its too w= asteful > >> then which one we should have. > > > > Hi Usama, > > my point is that with all the below three counters: > > 1. PSWPIN/PSWPOUT > > 2. ZSWPIN/ZSWPOUT > > 3. SWAPIN_SKIP/SWAPOUT_SKIP or (ZEROSWPIN, ZEROSWPOUT what ever) > > > > Shouldn't we have been able to determine the portion of zeromap > > swap indirectly? > > > > Hmm, I might be wrong, but I would have thought no? > > What if you swapout a zero folio, but then discard it? > zeromap_swpout would be incremented, but zeromap_swapin would not. I understand. It looks like we have two issues to tackle: 1. We shouldn't let zeromap swap in or out anything that vanishes into a black hole 2. We want to find out how much I/O/memory has been saved due to zeromap so= far >From my perspective, issue 1 requires a "fix", while issue 2 is more of an optimization. I consider issue 1 to be more critical because, after observing a phone running for some time, I've been able to roughly estimate the portion zeromap can help save using only PSWPOUT, ZSWPOUT, and SWAPOUT_SKIP, even without a SWPIN counter. However, I agree that issue 2 still holds significant value as a separate patch. Thanks Barry