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 3A598D12680 for ; Tue, 5 Nov 2024 10:57:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 876236B008A; Tue, 5 Nov 2024 05:57:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 827416B008C; Tue, 5 Nov 2024 05:57:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7148D6B0092; Tue, 5 Nov 2024 05:57:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 546EB6B008A for ; Tue, 5 Nov 2024 05:57:57 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 097CB1C3D3D for ; Tue, 5 Nov 2024 10:57:57 +0000 (UTC) X-FDA: 82751740722.16.3182783 Received: from mail-ua1-f50.google.com (mail-ua1-f50.google.com [209.85.222.50]) by imf30.hostedemail.com (Postfix) with ESMTP id EFA5780008 for ; Tue, 5 Nov 2024 10:56:52 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cNl+pVDK; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=21cnbao@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=1730804139; 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=P7XM9/dVatJ/H1vTPPYlueifW2nkKAEOY6leLXkNvBU=; b=VNJg1RFe7Slfp2Q7UmWieCwBjt51lXxu8ADGb7ItLizXd/4R8doh04BqQJelFv8AMrMkBZ gicamQPwshAoQZ4Dnb7uweQzW9/uRBPxNBIyVcI8z+P6o5UgJFn4lh+f3LatcSfjtrktLK /NdamCU6eRPtA56abPFu7pO8MYUXq3s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730804139; a=rsa-sha256; cv=none; b=qyj7LX7pjk1oidX4v85yqv9OFsAzGjGG/6lbnjLxNnODPyrpLNVhLnKJFv+F+8YAl/VTZs vhWiX+TXg9Ta4eHl8Vm8RnZ/npcLcGY3uge7VP6JsFMc9fvjIIDv6BI948qz48nHuRK/YP HCsToyOrqTXiL5KZ5RBu0VyLr6FbPYU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=cNl+pVDK; spf=pass (imf30.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.50 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f50.google.com with SMTP id a1e0cc1a2514c-85019a60523so1744634241.1 for ; Tue, 05 Nov 2024 02:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730804274; x=1731409074; 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=P7XM9/dVatJ/H1vTPPYlueifW2nkKAEOY6leLXkNvBU=; b=cNl+pVDKHce8Bd4nTYCLjab8OfYUA6yGwJpepXpFwSqr2+9LZMh7k0yZP5gA9S6fTk pLKVL5u1g0B4t+JMkBBn1XSIfvUlojBpmyvJt9NJZS6wZa+VWU9RTBSvSnLPy934Ajkv 8GV/8TJ/0wpOB9vVQlWOMot1OHU0s4yGq3vQhtm9dFwbMHWpKNTENSBqFXZzf9/PJQFg MAvtwfb4/496SLk0NDpPPTf3eHvH4TPt4Cs7ZRyCyYxWdKXB9mOHnMAluLen8Wd6WanD fiK6mr0xKMn/VdvCY9LXHjAI+Apa+ETuSibv+9e+l1CD/k/Pi4F0Z9XLQdHB9/EJuiLq 7mKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730804274; x=1731409074; 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=P7XM9/dVatJ/H1vTPPYlueifW2nkKAEOY6leLXkNvBU=; b=TbUlgs/4hcBAZA1QFeH+AY5H+NOASBXHp/tP3HRD1wCSA5IjgEyrb4aeK4gAtObnJZ Ftvwj+u0uzraJKMANYyBcP4ZMQsaxugo9cYUBG1KgodsXLi4I3D9hPkB6I3WCPqCqhyX KHTvlsgc9yyA+EOwzhlGfQgt1gyIM2Z9sOW47L5xI2JlRmWV2nqwvgd45FphMLJsxgZz zwwFY/Nf3pN+0i2d7qdYYgmytyLUU+gTr2qolIkUEURjIwjAlROLG072poVuzhM7DbyM SPkBBRyyDfsJwoclOACcCCBB5xtwB9cLvEb+wG0yoPYgqiOprHZW81qT+Uytr3vzS3/e 6+Cw== X-Forwarded-Encrypted: i=1; AJvYcCXyrcKOwZf6rPywExi/9V/6CZyNW3wA8UjJS+2+GDVh4p0DXc7/bE3nmGGJ9QQ2U2WToJnlNVbA2A==@kvack.org X-Gm-Message-State: AOJu0YwmiimEzH7TLZ/+78kKCD0VHrcjWLQWu2ZtuTM4CqUPLg3i1Uj+ YIg3Xy82VP2VPLjIlReMx5bjei8mlmFN16M2rpRyhn1layplstgPIO+0wyfewL4EjLWwjf5Kckm qxLzu1zR77/iCH36cdwfRHbdYPpU= X-Google-Smtp-Source: AGHT+IEEqhV2ShZtO63Bqg7YDE/NcvOL2RLWyDoJEGuu374QlVHH7YDRCwWJsuRQ4mqAdBvZcUYvoSEw30nNm6286K8= X-Received: by 2002:a05:6102:2aca:b0:4a7:4829:8c93 with SMTP id ada2fe7eead31-4a8cfb4b9d9mr33019569137.12.1730804274145; Tue, 05 Nov 2024 02:57:54 -0800 (PST) MIME-Version: 1.0 References: <20241102101240.35072-1-21cnbao@gmail.com> <6c14ab2c-7917-489b-b51e-401d208067f3@gmail.com> <3f943f72-59d6-4124-96b2-e0bb8d7a5ebd@redhat.com> <20241104194024.0284288a28a71a70a3eab9b0@linux-foundation.org> <942f8355-4b23-4fd9-b00e-1121552d89ee@redhat.com> <11bd51b2-fa2d-4d99-912a-563521aaa6da@gmail.com> In-Reply-To: <11bd51b2-fa2d-4d99-912a-563521aaa6da@gmail.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 5 Nov 2024 23:57:42 +1300 Message-ID: Subject: Re: [PATCH v2] mm: count zeromap read and set for swapout and swapin To: Usama Arif Cc: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Chengming Zhou , Yosry Ahmed , Nhat Pham , Johannes Weiner , Hugh Dickins , Matthew Wilcox , Shakeel Butt , Andi Kleen , Baolin Wang , Chris Li , "Huang, Ying" , Kairui Song , Ryan Roberts Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: EFA5780008 X-Stat-Signature: 35kappcn933yeurkcgjzq5awwtij97yu X-HE-Tag: 1730804212-331389 X-HE-Meta: U2FsdGVkX19gEOg+l2wZHA71zKUNmcBWgrTEKNzVpdeO/Nu8L+X5ndad0G8ajZygNodz+lq9DN/8xnSlIT3hZSvHoVwNORrtm+zvqtTzjrjcs/eO5EtzXDp0RRU0j6F6uA4aL9XrXdKAKUrVtdo22y3nsO9HnZ3+niDJq8vQs/fJ2sUHCyAQiD+cvaEDzXuoRRXmedpRRim7LoQ+Eg+E/Py/WwrNRIE18Z6pSMTKAgfaHwjcW9xTGQKedvDxnH1XzRfhOp7hrNCKFR26XOVcIwnBj5ASWh02Ks3UlaODmsDTXMn0IyPcEF3kZk6aCjV+Ssj7f9FhFHDzWf5WX1nbnXemGm63S8jz90ZZh23/z1UgLan22DKQxRegp1/ha0VBsNSEozwLLbgZDHR5il845I2vhFNNqyfN7K8HRqvzfkaumCcElfxDJjUiVwX1F0ng7ZVFGYo3QiYji6ZC20ze0WHksEVAzKnJLEdKkMzNR8bm1t6LlUxhqF9VR+e9lkC9WwSHl0sT+CpMKD2krpujY356LUNgh0NYMISxi1FY58OZL2v5EDr+pDjO2hxNEbw/x678yOvuEPCDwpWrpR2YYukcU9sBcBSkMyvqPRqhK8VTEE62xs2JOTwWemUon+9rKI4fYIK/uV7EMjlOKC2k0JoJDDkmNiMk2j+W7jGu43mGS83BF29G9vnBHPb34/HtMe5mG6TVAMnYP+NxnTFNOC5e89ON0uRA2WQp/I3gjl4M6hKafXy9k/ezjIlf5QAywWnqTukJtz+lPlw8kNb+2mw9a7zj/DVICwXqfHFQCvdc7H8ZGjld3sv/bSiSH3meZIw5SdNlW3TH8f9ZRf2UiZBJ9ZvSdqxowsLKh+32LiIKD65/ZAUrwjSVJARNBOLHsOmGr6LZS+C+z00Yq1yjAgiCMCriT6cTUd4pPDRdgKnUPOeapaFV2W9L3S383yzRt2xBto2rmxM+rhlaQpA vS0kHTph 0YI+mJakXhE1vQ6ILpCurFAL9NWhxiVXsmGe4Lls3b49QnqH/qqBo9NMJV7ZBf2wEP2blPlF8WjSd7IcWO01gpOL9mTDzKotP5ypDu6OZK9Uivqq/BQs4GirrDBNwcaaIg9Hlupdxm/dmvzYfvNRAVYGuDRAdaBfTFrs/QNFC4gj+AsbSQ4jgnYMn1/AYkfRnEjG0kH/U2jeHwzlwqP57VY0DsMO60kebqw6LxO+GSXViwV+e5RqdcMKLqtqLHh2rmRqfqEmqTJ3h+3Pr17FvCmpzo+U1FV0pWX/cib1hwJVHBlZLjfm/7Svf/l5A33YRVGe2fTsIE6n5pU64IW7VS/xcboI7C5GNb27M3JDTqAPvZ8Qd0C31kjkU9dgp23IFpfKji4mhyBP4lFY= 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 11:44=E2=80=AFPM Usama Arif = wrote: > > > > On 05/11/2024 09:15, Barry Song wrote: > > On Tue, Nov 5, 2024 at 9:23=E2=80=AFPM David Hildenbrand wrote: > >> > >> On 05.11.24 04:40, Andrew Morton wrote: > >>> On Mon, 4 Nov 2024 13:32:55 +0100 David Hildenbrand wrote: > >>> > >>>>> As mentioned above, this isn't about fixing a bug; it's simply to e= nsure > >>>>> that swap-related metrics don't disappear. > >>>> > >>>> Documentation/process/submitting-patches.rst: > >>>> > >>>> "A Fixes: tag indicates that the patch fixes an issue in a previous > >>>> commit. It is used to make it easy to determine where a bug originat= ed, > >>>> which can help review a bug fix." > >>>> > >>>> If there is no BUG, I'm afraid you are abusing that tag. > >>> > >>> I think the abuse is reasonable. We have no Should-be-included-with:= . > >> > >> A "Belongs-to:" might make sense, for this kind of stuff that is still > >> only in an RFC. Or we update the doc to explicitly spell out this > >> special case of using "Fixes" to sort out something into the RC. > >> > >> Because if this would be already in a released kernel, it would get a > >> bit trickier: stable rules explicitly spell out "fix a real bug". > >> > >>> > >>> 0ca0c24e3211 is only in 6.12-rcX so this is the time to make > >>> userspace-visible tweaks, so the 6.12 interfaces are the same as the > >>> 6.13+ interfaces (which is what I think is happening here?) > >> > > And including the Fixes in this patch might be useful to someone = who is > >>> backporting 0ca0c24e3211 into some earlier kernel for their own > >>> purposes. > >> > >> Just to be clear: adding new counters would hardly be fixing existing > >> tools that perform calculations based on existing counters. So we are > >> already changing the "userspace-visible" portion in some way, and I ha= ve > >> no idea what in vmstat we consider "stable". > >> > >> But I still don't think it's all that big of a deal except in some > >> handcrafted scenarios hardly anybody cares about; the cover letter is > >> also pretty clear on that. > > > > I may have been mistaken in the cover letter. According to the zswap da= ta Usama > > provided for servers, zero-filled pages accounted for about 1%. > > 10% not 1% (https://lore.kernel.org/all/20240612124750.2220726-1-usamaari= f642@gmail.com/). > Sorry. My memory must have faded; my mind is confused by the 1% non-zero same-page data and the 10% same-page data. Getting old :-) > > So > > really doesn't > > matter too much, but I just checked with Hailong from our team=E2=80=94= he has data > > on same-page-filled usage in Android apps, which on average show 3-4% > > same-page-filled, with over 85% being zero-filled. Some apps even reach > > 6-7% zero-filled pages. We previously used these counters to profile > > optimizations, but with zeromap now serving as the frontend for swap fi= les, > > those counters will disappear entirely from both zRAM and pswpin/pswpou= t > > metrics, as folios are filtered earlier. > > > This is what I meant in https://lore.kernel.org/all/79deed1a-9b0e-42e0-be= 2f-f0c3ef5fee11@gmail.com/ > when I said it affects zram as well! > > I am happy with the current version of the patch, just need the change > in Documentation/admin-guide/cgroup-v2.rst. I will update the document and send version 3 tomorrow, incorporating both your comments on "zero-filled" and David's suggestion regarding "move out o= f memory". > > Thanks, > Usama > > > Hailong essentially has a table that looks like the below which could b= e > > collected from the existing counters: > > > > com.xxx.app 5% same-page-filled. 88% zero > > com.yyy.app 6% same-page-filled. 85% zero > > com.zzz.map 6.7 same-page-filled. 88% zero > > .... > > > > Anyone on 6.12 will be unable to track zero-filled pages unless they > > backport this patch from a newer kernel version if it doesn=E2=80=99t m= ake it > > into 6.12. > > > > Whether it's marked as 'Belongs-to:' or 'Fixes:', I'd prefer we aim to > > land it in > > 6.12 :-) > > > >> > >> So I'll shut up now and let people figure out the naming first, and if= a > >> new counter is required at all :) > >> > >> -- > >> Cheers, > >> > >> David / dhildenb > >> > > Thanks Barry