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 36901D5B154 for ; Mon, 28 Oct 2024 20:51:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A85E76B009C; Mon, 28 Oct 2024 16:51:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A34466B00A5; Mon, 28 Oct 2024 16:51:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FC6B6B00A6; Mon, 28 Oct 2024 16:51:24 -0400 (EDT) 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 723686B00A5 for ; Mon, 28 Oct 2024 16:51:24 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 180021C4D3F for ; Mon, 28 Oct 2024 20:51:24 +0000 (UTC) X-FDA: 82724205774.23.A87FBF0 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by imf18.hostedemail.com (Postfix) with ESMTP id AC17E1C001F for ; Mon, 28 Oct 2024 20:51:11 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jCoF96WH; spf=pass (imf18.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.128.49 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=1730148523; 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=JHXlbXtup6m7s/te+MX8GjiwOo8k3bhse/14tGb+nrg=; b=mNVfaqQcwzDLbLNgCSVzQ27cmP8AwkeeZ9oy9T5udlodXXKj7GP7uHK1VVUqVIZ0lKB95Z c+e+xM9SpZ/QYShVQREQNRjKF8wopnl40EqgZhkQNHudY374O8NVS85L2B8ItOLGwVhKIL M7e/uGulP27IBb5rzswKRRZ4+xMM8HI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730148523; a=rsa-sha256; cv=none; b=N6hnSCFprKiixu/Ygb4qlsfRab/CDhrVdgGUthBRT6wM/VFz9mLoUbtxfJdYzA7lKvOC66 LSeyPwEWqkS2psMkjAU2lestgxYxqTlUm2fdYFikB5BQigwBBV5wtoQ+wCe2f3GGK9emOu AtH3GDIWpEER/JfiCaJczGz13zRHOkY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jCoF96WH; spf=pass (imf18.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.128.49 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4315839a7c9so49474405e9.3 for ; Mon, 28 Oct 2024 13:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730148681; x=1730753481; 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=JHXlbXtup6m7s/te+MX8GjiwOo8k3bhse/14tGb+nrg=; b=jCoF96WHJCciYnn5Wf3+twbs+f/vWx9vYmMfbgOTX7dktaUiTdlIYAgGlgy4TckkSY 1kJErmPSjHKssPvcvT7DtIYfS3tq6ZuQJm/7U0A8hRwHyGxhQkrXrbzlsdIthq8Jzql/ Gi4CLFoNQg3IZOQWRg+OvOxXAdx5wXgh7aHTMT2GDpq2iDEBGKam+SUMWguZ7Kalt3OK qqVHpPKfjkMn4aB0C6UioVQXfhfHurUoTulVHPKm+Om8VDX3oSib1gt7mVXjxlA1Fwt5 Eim8CbPap6Kp5q3Hg9xI/y0kfH48M/5IULemRuCFUDkrHV9SnxoIBbgjEIsuWvD9uXAp MBxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730148681; x=1730753481; 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=JHXlbXtup6m7s/te+MX8GjiwOo8k3bhse/14tGb+nrg=; b=GjX5HixTiSMRirxMQdMM5Ybr0xCEOsD7u1KPZr13n3D3C7leZlNrDef3Yj3kWwkZBC 5C4Qj/fxo+DUYx017COjfvxqTE/KU+VZ3C91ZxHAmn1PzUxW8P5ZDdpEmC6oI/eAYXJ9 MZZkVwFOJUfYEOKoMye09oAsxTCgjCO+jP5CNvtohiVrUephJA8sARpCP7Y12chrR/jy 1MHX69f8Od/OJWZKJVKt7ZHl+zlaMueJ1rFX8fJckUCAQHjI9akj75C4UYVtRXzpaHFu fGj9mtQUhLFYCF9rTl7/6FH9L1SqC9QjJtYKFIYxsRabiILWRNM1YZF75mF4bv+hU+MU ZTig== X-Forwarded-Encrypted: i=1; AJvYcCWUfRl6L3uNPR5HgFCswiVbJF76ziCcr8KSHhQuquXt6A4oL8hcgUJbJqJgf8ZWXardEVD/Ao2Qww==@kvack.org X-Gm-Message-State: AOJu0YyqtOc7fgeciJKspcWtfbEJq/4JJy75btUv++CGkLtgOf7z0osG pNN0Q0PfOs+zrT2FCNz+U0AeB7XGAWC3+Uw1gtzpjc3GBXIfchqP X-Google-Smtp-Source: AGHT+IHnD4xFnI/N9uQW6KYyRVhqpIL2q427+H12phCUrAMGFlJ7IG9Nez9zeX0T+gWoI+k0m7lbhQ== X-Received: by 2002:a05:600c:354c:b0:426:6455:f124 with SMTP id 5b1f17b1804b1-4319ab8dfeemr82605525e9.0.1730148680411; Mon, 28 Oct 2024 13:51:20 -0700 (PDT) Received: from ?IPV6:2a02:6b67:d751:7400:c2b:f323:d172:e42a? ([2a02:6b67:d751:7400:c2b:f323:d172:e42a]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38058b712cbsm10562317f8f.77.2024.10.28.13.51.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Oct 2024 13:51:20 -0700 (PDT) Message-ID: Date: Mon, 28 Oct 2024 20:51:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC] mm: count zeromap read and set for swapout and swapin To: Barry Song <21cnbao@gmail.com> 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 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> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: jjqbiff8qrqniz19juxopk3gh31a1to5 X-Rspamd-Queue-Id: AC17E1C001F X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1730148671-589842 X-HE-Meta: U2FsdGVkX19E7bctEPiLbcbvk6p3rdE064Y4fk7HltylU1o2bAHnHWvieJnbywmEy3uet8ZkOdfYIt1soW6iMb6/rPJ8++u2TgiY7iunDEMUWYbvyhotfWCfS1HLNiy2q8UC0tPSVGKcM27pAclY+t6As4frgV/piGNY6SrVmF5wHnC/deneLxaCFdkZxzDuVg6aLC8cMOjcW0B/GGmAct9DTybxOl93kYmVTp/Y0fyfaY0opHtY4igleronBqxaLWfqlhL9E4V2wNMta28CzQ73BRd/2BwT5R+7uZkSnEkTilDcPHE7O60pS6ooj2wsdI3ngiKUFhNHMVE5BQCh88RJLtlZNAhyr4y7l25K2C0RxSgPmNdRkFeyCnjQ4gd5X5I4LWnW77cGj2hA3r2VzEZoiAw8SaCxx4YBR+0JN07TDkuvP/we7lc1QxD62enV7EPZJoJk/+IViYavFtmyAw+JYTp3/13VfbMVHcdJArAkwpdjIEzKycESQday6dVECZAMJ9wyr+xFIfpsSSUvtHs18mCo0bJ03nEp5ob1j6Z5+wHho/EEa5woZoOXMhgR3iilNWq0qlGYzk+ZV285iUBuLRyCoSLSIbsRsz5hNBi57ohJ3v+9neqfvO0eYba/wg+XR23S1Rxd6tJ1wTErTec9GlfYIGzmC6KWT8J3pwJ98ZE5OJ3+0MAQtPEuPnB3+3d8N10iKGo32db/PcSbMWBHa1G7nLzlCq73C/Z8Az6nvOLVg+hxDLN8V9zdhW1EsvXw2Uxbw1zu1YZr/iC2OdwvCU7F5YxQ76EKY5NRm38KQjO9EysgAN0kEkNmLOQoAVW0lT1ffj9PVBFrYutOb86Xrq1nCXds07ruXxSkUUX25UqY+8/lK+YRpYhek2UJnnKiVOhyNqg+LoyU5MEb0fSHMwJC7agAsfaQZZo1u2gwn3OJblEkSbnbOB4GRoGytKobsKB3Lwb6zI5O0fL 5eYe/7ez DxnymUEPiUPQ4lobOTTuiCoi5XMm3/IB9X+5rfJE3nceCk8cUYVHdY3fT2QIX9ov+ta7/Nyz0Y68hDtqiRvdLWswXMfNf9bOfjkSiSP33WnsFbqU73Q6OWmavQIwhrkP1GvjQdO4xpHvDn9Wu6Rwvx12hJwftNBjiL+KbB0bKy1Pcu3FoaZte60n6KXhH5VNFg9H2u/FckyqkHdub3PoanDm0TQCwBTrtq92fzqFDhOFeglZI6k0SYvCri0JJp+MDR6QYornmTokBupfXh5bRsXMqjebIL+1mX27yXVPihSoLA7nTMfw1IVs/FpDAF06iT0YhWVIznYA6vOhmO55qaBy0czLlcIKY3HuLgLmw56Ut6K6CjY1gnXjXpE18yNli7pynOszrVGBnda12qz+dLhul5iJjsCHue4uW3O26Th9C27d+fnrZoLixbTFKcPUtw8mYm9Vtxd+ivmUZoVMJHPK0Um7+Rs9TwngDnlQ0XAF9v/c9L1W14EEu56Hu+hBn6qwkZUcQbFdlc2LwUfUTbr6QroD4i3a2hn/jtCJsysXCfiEqFY54B0SkZw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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 28/10/2024 20:42, Barry Song wrote: > On Tue, Oct 29, 2024 at 4:00 AM Usama Arif wrote: >> >> >> >> On 28/10/2024 19:54, Barry Song wrote: >>> On Tue, Oct 29, 2024 at 1:20 AM Usama Arif wrote: >>>> >>>> >>>> >>>> On 28/10/2024 17:08, Yosry Ahmed wrote: >>>>> On Mon, Oct 28, 2024 at 10:00 AM Usama Arif wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 28/10/2024 16:33, Nhat Pham wrote: >>>>>>> On Mon, Oct 28, 2024 at 5:23 AM 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 this >>>>>>>> patch, but would give more insight of the current state of the system. >>>>>>>> >>>>>>>> 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 information, 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 about >>>>>> 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 ofcourse 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 wasteful >>>> 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. Hmm I dont understand why point 1 would be an issue. If its discarded thats fine as far as I can see. As a reference, memory.stat.zswapped != memory.stat.zswapout - memory.stat.zswapin. Because zswapped would take into account swapped out anon memory freed, MADV_FREE, shmem truncate, etc as Yosry said about zeromap, But zswapout and zswapin dont. > > 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