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 5DC31D12663 for ; Tue, 5 Nov 2024 09:15:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0C526B0089; Tue, 5 Nov 2024 04:15:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CBCDF6B008A; Tue, 5 Nov 2024 04:15:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B849D6B008C; Tue, 5 Nov 2024 04:15:54 -0500 (EST) 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 9C33E6B0089 for ; Tue, 5 Nov 2024 04:15:54 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4AF1A40FDB for ; Tue, 5 Nov 2024 09:15:54 +0000 (UTC) X-FDA: 82751482548.01.0A9501C Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com [209.85.222.49]) by imf28.hostedemail.com (Postfix) with ESMTP id 0CE0EC000A for ; Tue, 5 Nov 2024 09:15:18 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=l7mdprB6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.49 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=1730798069; 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=zKulzpeoz60rUZHGWKkvRHEIspxK1xcPTRYy4usyVBk=; b=TBSrgOZcU/ea15ZOLDNwQJKedkoWOGqZDiV6cEpMwA6iqxHz4aYSChzUd6R0i8r8Ix2NOF O6PoUZ1J22bkJ7nZ6S2SYdmnLOMogvrexgWTtYUIsQ+/nEqyA5TIYS3/aAYg5Yw3oapzNJ gEDhNlD2yg2S/+v/vAkjYX56jusv3p8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=l7mdprB6; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.49 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730798069; a=rsa-sha256; cv=none; b=aQOqXFwMKROZfNtTg/85/8eGIF8Ws0mLPAfRPDf3+v7QHUeRvS1nCL2RXFqbBMECnyZX/X gPF8P6kIMFUvu5K7IWQh3vas2z+ATTawdJtFY+4aq7OGmfNePjslXx/A66Fny+SRNEPmMw 6RIOFdqKjAOXTz6qjP8Ctnhi/d2EFbg= Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-84fdf96b31aso1825122241.2 for ; Tue, 05 Nov 2024 01:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730798151; x=1731402951; 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=zKulzpeoz60rUZHGWKkvRHEIspxK1xcPTRYy4usyVBk=; b=l7mdprB6p6GwXa8KLt+Wi4XWaIuu9jXTBvPc/KjT/qpuh386l2ikCEDrsLh2xpNmks gMCK7EK93bixm5YvNF7Or5pVGS3/9RMroEEcGDgmQX9JxvphIRNE0s30zy8jtXyIovC/ lOKIF3eRnOwbyr+pcbL7JdHrxVlh2iMRpXx61lmiDfxIu+JyI5rUz//axmUxOUYJaoy8 PMUve53jX9WGe1/Zu7XCTlbBuA0XzpnJnlQ9o8OCM7myYiKghRsR9OJt7/Zx0zfq9zbk ghAi7JvdAHR63JsFxRTvnEEN6V75yXQ3o5fQknXyBMZomhXk/o+amCuSJ9Rd8B45kOag bGNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730798151; x=1731402951; 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=zKulzpeoz60rUZHGWKkvRHEIspxK1xcPTRYy4usyVBk=; b=LTs6oggwqLu01RqeZc3wjtCmaH6an8AReGLhCkUWAHgqV1LfU2qaMD2N+vx8frGJ6h PVrVXtebYyErhh+V1gaPO33C9bgRXg5f8pIsDhps7h4mvBg/1Y4Dfyyn+vNkmjNvkigx ra2KJux57IhL35EVnIHBz58BqFLQ9I9L8kIMrOSVtGdpO25iSqkGKiLHIVQPMgJNLSH5 NFKTIRYLaVm7NcaMGXEHZ4l5UpYdWxWs6RtfA9rTyWHA6KmrSFXaDQhRj39bYCkf0uIh yAxurcxEH+pTSTDAZTt5sKkosPB8O7zIMbWdCbAh/Uoh1Lko7w/QKiYawtdH4Kgoho0H Advw== X-Forwarded-Encrypted: i=1; AJvYcCVn89QuIQWcJ/ta+fW3Z3CoVieqDgKVvwb0M6vUReqv5oUFrG53pS6wR1RQNeyU1/dO2gSfF7GYSA==@kvack.org X-Gm-Message-State: AOJu0Yx9uoJXhorZ7mD5v8t40cbQUfl9wlhg9h2DBsOoqQwJtFUmw0qn aico+T9uN0+p87+W9Q++APltHFy+ShfnToKP18yKQz1CzSRhAtTOIHqIFYNxEKuGoLfn+KUO+8/ 95Qi397DPBQHQYZrFXE4jB9ImS6k= X-Google-Smtp-Source: AGHT+IEueJnbGiwtInCCyi3lkcDcZZNl6kPDvfAubTF4J5Wy0inNePEJV5BaqMzx40PuALKVAyefwzRWoFHpcOyLDTU= X-Received: by 2002:a05:6102:3a10:b0:4a9:49:26d2 with SMTP id ada2fe7eead31-4a90109fb68mr21241050137.29.1730798151459; Tue, 05 Nov 2024 01:15:51 -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> In-Reply-To: <942f8355-4b23-4fd9-b00e-1121552d89ee@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Tue, 5 Nov 2024 22:15:40 +1300 Message-ID: Subject: Re: [PATCH v2] mm: count zeromap read and set for swapout and swapin To: David Hildenbrand Cc: Andrew Morton , Usama Arif , 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: rspam03 X-Rspamd-Queue-Id: 0CE0EC000A X-Stat-Signature: q1ju3jr8tdii8y51n1j4onuc8jc1b9f9 X-HE-Tag: 1730798118-904256 X-HE-Meta: U2FsdGVkX19IFhyAuII/ynxJzbj4Su2YkJXq4lvJminClsjfsaj+D8QotoWi6ewWzGS4RpE07ddZfkD0PSBPQ5XNyR8DXTpaeytz1k+KtBOOi96eUuf9D6kC1Vu5/Pw+8ecwaXLHs4qWOv0+8kzTX7/2uw/C+dS3I61nSE0CJ3Hk/xREfFaljxQqlWi6gDWwq/xMpi/3g7W6/mz1pEyAPSdnN6leOkTfQ/pKBtFC+2+dp209YeGAtXCc7sJoPDzLi1Cd8u5NE3MeaPzry2Xu6S0mvrG15D72fO0BgY33kvclHhuTREx663+nu+ZiWv09Jds73ytC1sWjc7pKMLvVfCwWKWrcV64vpEStMvfg5MdKHUhkWhDPHbGJ3cni3Z9z9M/7bCCCxnsBS7Lc+0rXWAbEY+IP1nZc/TXZN+B5ddU2NO7au71Al0Gkf2F/aUlO4h1m/NZohLrW+Za9XmmE+q040AT0v5WFOPi7imIXbuLhhsdWfRYtZ9RtN/j7cEUEeMl/fWseApzikc0Ya6BB6/gv1bY5kzq44Kmw/nx84zoy2vl/mIC+mJwth56Thddd7lk/KqD7aNaxMss8mi66zXenkrCBmu4lS+0EJK4TzGfTryNWw2/oZeJn1TfMms8dMGiK12fO0Ll/rHMkQGrxNSZk7ubVreIHSuRvkiPStvKYW/0rwB69Jk+k2WUiwRA1llT9/RityeuCULWXVsdGNU1r1rhiXN5OJ8rpHLpV5cZWnKpdA2EWcjiic0z9+jkL7sJGBTdsROGZTDsCj/+/3A6ZLs3eOCYeySvgv6QyXmaCLcI2wxofNcsv19Bn+JZXVO2H5GbiZN8MnOIPTV+lLgt2m+LdqkDvBNetkoxP8BeE9k4/gCOKPDxWzM6M19Dsry2wb66Qx7wgiysuvsD6Nr3CWoa8UZ65QW2B0f2bdcKsrpTa/nB/N7PwfOrGb+VRbM6DXWZ2VWEx2ISka2a mG8T1aDL lo/ErGhs7IWExzXvYplo9PL/c5vE5NTvm27MzdFgQH+kHr2qRK3s0EY0p4/imS2GhxR5nrotlAPAthzxWGETL3Qc8tUmpHXzMSW3oyWlIxJHsDJiLbzBt4QqBrompWQH5k4svb0skznWi2CqWcpg4fbKwnuRFMSVymTJMe4PC9T5v96HBK1xbzOKuz6QgyJxz8GEGFRafNG+Ff2iWf4Ci+2Nn7QX1HuM7/e3Juc0HOCjT5rciadWXJPJYL8RafOSJqqFIqKQrXFA3H9YajtWmp/T3tY0HLyUD7e7guTUeMijcWfDDgHTCu6LsFk8LOCv7yUutm2PEiQGrePR3jT2z7TUQwA== 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 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 ens= ure > >>> 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 originated= , > >> 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 have > 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 data U= sama provided for servers, zero-filled pages accounted for about 1%. So really doesn't matter too much, but I just checked with Hailong from our team=E2=80=94he h= as 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 files, those counters will disappear entirely from both zRAM and pswpin/pswpout metrics, as folios are filtered earlier. Hailong essentially has a table that looks like the below which could be 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 make = 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