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 A1907D59F6C for ; Wed, 6 Nov 2024 20:01:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 371146B00AB; Wed, 6 Nov 2024 15:01:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3200D6B00AC; Wed, 6 Nov 2024 15:01:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E86C6B00AD; Wed, 6 Nov 2024 15:01:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 021F16B00AB for ; Wed, 6 Nov 2024 15:01:29 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B807C1A0385 for ; Wed, 6 Nov 2024 20:01:29 +0000 (UTC) X-FDA: 82756738344.08.A293BF0 Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) by imf24.hostedemail.com (Postfix) with ESMTP id 6DCAD18001B for ; Wed, 6 Nov 2024 20:01:22 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YEeNnSSO; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.161.54 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=1730923101; 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=lr74ySSLf5fxQH2o6kKiS46c4VRHrk3SnGBZdLF2hfk=; b=46xCZ3gv8vV8LUmarNk/3JjM/FR1h5M68gKk9bVY6Uf4gEF8RnE9MenzyREQo4Ze8SZNb+ Adu7F/BNN58vaI2QCKwWf3VQ0Z+ORMSUzLSa7rQY8g2xBdrTD13/hATpb5LNz9BDwVBZed uZVREYEfJ92C6kE2klOFrAFnBsfx8F0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YEeNnSSO; spf=pass (imf24.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.161.54 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730923101; a=rsa-sha256; cv=none; b=AVpIF3v2wSjbc38nIE2BAZvdAuGop8oS95PPTg1ci4mabGeOL7xjjH1RuRImhV8hnwT5GS RR5LdqkxIW1NluA8HBzY0kLrC0zIgb8K0oBWc/17Anc2zW7RXcBYuxlHbEA5k8u2scfN/5 kaIZOivZ/jgdMOlJzVXhDQ2XST2ZlP8= Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5ee354637b4so109747eaf.3 for ; Wed, 06 Nov 2024 12:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730923286; x=1731528086; 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=lr74ySSLf5fxQH2o6kKiS46c4VRHrk3SnGBZdLF2hfk=; b=YEeNnSSOgQi3LwQ4/GuK/uJgcCydamEVYuKVsuHO8OZOrvQW+ls19PaRNfAq9tuCeD w8BBZev2NwBP4O7GTfwzuEPp11l92IokNMFRNl22hXgDfrQ7kXyL+m8NiK5GLYNEIDgv 9IkNgI7ebGNIFTWsa59jM3zTWtesIUgTN4YZJ9TyIDLvD9J/t2lrlHxP1DBHufp6GQwU K1Rr4gdiJSGVwuOGnuc/g6cdh5Fc0WWyy76JzjQIAmWtbxvjRzQCBAnq1zuqbr26N81u 2Ul6Z3N3Yd9krDHOJ5kmVvuDVbzq+BEbLzOu8znTsHBHCSO8H9KZhbm7vfN4ygUMHWbk 4kig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730923286; x=1731528086; 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=lr74ySSLf5fxQH2o6kKiS46c4VRHrk3SnGBZdLF2hfk=; b=EORs7EXrr5qTf+8YqivFzV9fVpq+KjK6bxyr4cHSdSDGndHZZ7HceAl/U1lLNkurKa Ny9a3cNgbkiLx0eUHQA8NcFglpY9eawaZmQXLvjmE0xdAsTv4slcS2x5K4LoZ3GdKo4z Zd+9oR4ZdlQ4Mn0XYQdVGqhP8nf/vxYGcVQzbKdPFtrKEQHL1F1Pt91IJ3BlIqCRMJm8 pfn0peQF8Fn/8kQZqjNTWB+2rEUMT3qPR30eOUkvTf0ffRrpKqSVQTvZU7PmRyfKuHBx etP4QJRZE6tj30zw01u2QF7Ksjp1Lb4/0YyfUD6WWT1mr2rBUsSC6lXCaZ8WGdTGnopz serQ== X-Forwarded-Encrypted: i=1; AJvYcCW4xOB06IgQEfrkcbMHRWULISisve4vjnWqzW985gvX5Zq5Fk8l9/Qxjyyd6RdWixsW45h58tzdhg==@kvack.org X-Gm-Message-State: AOJu0Yyn/6Zn1D/pIqnExZogx3y69TRoKIt9RuUwEbN9JpAChr79oiDd jYzlp86S7CFa6TLfW7qRHsbemSRUfQV4bKA0YVQAsOFageH4Ja9sXRhX4/eY4bNhydqYIgekP3a 6jmd8+YZQ5QjKPqHK0yHQh0wL4zA= X-Google-Smtp-Source: AGHT+IFoPiBUrTrffy0X8fy7FjiYQMjqbgK55GJLKvYYJcgYflSdmLS+zuwS5Fc03HI1i9OCgrJsO9GP99yeCOHL8Bg= X-Received: by 2002:a05:6358:5295:b0:1b8:34fb:9696 with SMTP id e5c5f4694b2df-1c3f9e976b7mr2055978155d.14.1730923285755; Wed, 06 Nov 2024 12:01:25 -0800 (PST) MIME-Version: 1.0 References: <20241105211934.5083-1-21cnbao@gmail.com> <20241106150631.GA1172372@cmpxchg.org> In-Reply-To: <20241106150631.GA1172372@cmpxchg.org> From: Barry Song <21cnbao@gmail.com> Date: Thu, 7 Nov 2024 09:01:14 +1300 Message-ID: Subject: Re: [PATCH v3] mm: count zeromap read and set for swapout and swapin To: Johannes Weiner Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Nhat Pham , Usama Arif , Chengming Zhou , Yosry Ahmed , Hailong Liu , David Hildenbrand , 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6DCAD18001B X-Stat-Signature: oobze9igapxrpwgr9zemdmaangid6t9p X-Rspam-User: X-HE-Tag: 1730923282-973683 X-HE-Meta: U2FsdGVkX19GC1I8i9R5E0ZgXOfuWpp2d1B9ii6QQm8ibSyEagbbduE2atJlo1cJpMV5HcFQS2vIGG0jqcQy8k9H/OF+W3jgBRFGVpdoIBF+Cg4iwDyo7MyVcAteBNKNg6QRw7plorVXDn+rPDMhtgeNewE3qsixYUl3cE0wPiA+kXnvr9fKtgCewTgGxxPH2FfuHAXbYuzECcB/pXNQMKmK5GFYyVA8rjYZwC8ML7gNDoqmpukdBM16Uz0bFJRDfTB6WmcHSqjPXz8IMQpcFE/CMyP04VR84oBOTZ2wNcoAnkVOxjbF4KfPVmnzQ8a8Ay+vqbefPnZvLO+j2SRo/Fs0h3JvsknH2YoqwKqM7VNo8M6sQeHzIfcaFCUXHfHFC1xlFKbtjTvxqmKZV8IjEJlhzndltOLvR1/bPgDpI1iWWUXGrgvUDlt7bRgbwrEUv/0i7O8BTQvgCbsALlP0hVbRIs5w0VxabxBhLpLGmxbxjYfBWMxOCAb8iNfeC4f3ozwKNgFDcYp/qHWp5kSPMJZCkAOPJW/0IZYueH26wiaxO/2vADqmkDfmYasgfXGaFwMrDLhA2l/k79Kh/CgAB5C5A7RXR0i/TA7Y2OjhR1+w4owXn8KflPL0zczRtF6JwMaaCo6zP3JIG9ZgtpCxMyURBEAB2FAurqWXTvBP28meXAJvUyKDm2Bj3nKSpL7wYloMotBEZK/zlWGz8p+XXP8Tt2qTaSHAHZB0hWu9u/aIO7EE67eNEtollFN+2+S+JPX6jmCTwFRBjpRIEy4LFMr4jni7+mHml3CKwRt3C7PRBwPFLZp8FCrDdRG9N0MOGf7SJi56mBViTyPNnKEvyBbUTFEfxZDWr6Uzdhx8jddhSkRgaDAmLV1friko3N89RUkULx2CqNof7VJbQrKO66lqT/JhRfsi820FTJZV9AvvCFiU+THrT7GB/VV+KjH456xBVIypdJAyJOpF5gb bJRhTlLX uxH8l9f8+gmXfB+2bvjJnxLm5MiHjdqHz4E3CRwvQFH6CGxOlx1iWENQR+rjrtPJFPEhXk7iKbrj6zJw2it4fhh6cm4BY8aezzm5rkkFC8noqbXtx/1hRY4wwQg4oDDCgZQ5yx4uKd1mAp8Ei3eyoQP9wogn7GGhWNKgNLS1KmvgANUNyaRa7toBpjBop2Iw0bNsAfOT1d2TGYBFF2ecP17eHIlOQ0a5mgvoPfUQCMd6xLbWr/rp46QxeIYXI2Gy89xnW9gXhUR3qeYFeFRGLGjhO2shp/QvdK/jZHvTKL8y3h5JBoQSeTQmtBg0YU/T70l+JesP4Ti7SkgaYlyrFK6FsVWv28eOGX96KZzpjH6rk7d5AfguKGwPsYog5pvuUPwlyzl8go2YmWGDB6yFktKUNh9YOL8NMuUdlKrRMKNGf4FQZNcQJQzyrGuJWAHoeYBmWhxzCpDPWXqkT7n1sCu3teVdSSR2O5lMPHF6RL3rINvf0Ik5T1za3SReMoVGON1K54HIHLDDWwjhLacoP8IaLC6rxIVrNfdkEJDdfaAHaXRaFzNHQpWhixq9WD9Jn/O4MJmIFXvwGWUFWsZwOqvVlgtf2Qq1SBIWII2XbGpewOmAXivIACRZB/yg1l/Dk89B48wFzKr5JyMsoVlEJ4SScBWXRMGoFksFHCgDB8jIJKVkEHmCqr+WIBg== 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 Thu, Nov 7, 2024 at 4:06=E2=80=AFAM Johannes Weiner = wrote: > > On Wed, Nov 06, 2024 at 10:19:34AM +1300, Barry Song wrote: > > From: Barry Song > > > > When the proportion of folios from the zeromap is small, missing their > > accounting may not significantly impact profiling. However, it=E2=80=99= s easy > > to construct a scenario where this becomes an issue=E2=80=94for example= , > > allocating 1 GB of memory, writing zeros from userspace, followed by > > MADV_PAGEOUT, and then swapping it back in. In this case, the swap-out > > and swap-in counts seem to vanish into a black hole, potentially > > causing semantic ambiguity. > > > > On the other hand, Usama reported that zero-filled pages can exceed 10%= in > > workloads utilizing zswap, while Hailong noted that some app in Android > > have more than 6% zero-filled pages. Before commit 0ca0c24e3211 ("mm: s= tore > > zero pages to be swapped out in a bitmap"), both zswap and zRAM impleme= nted > > similar optimizations, leading to these optimized-out pages being count= ed > > in either zswap or zRAM counters (with pswpin/pswpout also increasing f= or > > zRAM). With zeromap functioning prior to both zswap and zRAM, userspace > > will no longer detect these swap-out and swap-in actions. > > > > We have three ways to address this: > > > > 1. Introduce a dedicated counter specifically for the zeromap. > > 2. Use pswpin/pswpout accounting, treating the zero map as a standard > > backend. This approach aligns with zRAM's current handling of > > same-page fills at the device level. However, it would mean losing > > the optimized-out page counters previously available in zRAM and > > would not align with systems using zswap. Additionally, as noted by > > Nhat Pham, pswpin/pswpout counters apply only to I/O done directly > > to the backend device. > > 3. Count zeromap pages under zswap, aligning with system behavior when > > zswap is enabled. However, this would not be consistent with zRAM, > > nor would it align with systems lacking both zswap and zRAM. > > > > Given the complications with options 2 and 3, this patch selects > > option 1. > > > > We can find these counters from /proc/vmstat (counters for the whole > > system) and memcg's memory.stat (counters for the interested memcg). > > > > For example: > > > > $ grep -E 'swpin_zero|swpout_zero' /proc/vmstat > > swpin_zero 1648 > > swpout_zero 33536 > > > > $ grep -E 'swpin_zero|swpout_zero' /sys/fs/cgroup/system.slice/memory.s= tat > > swpin_zero 3905 > > swpout_zero 3985 > > > > This patch does not address any specific zeromap bug, but the missing > > swpout and swpin counts for zero-filled pages can be highly confusing > > and may mislead user-space agents that rely on changes in these counter= s > > as indicators. Therefore, we add a Fixes tag to encourage the inclusion > > of this counter in any kernel versions with zeromap. > > > > Fixes: 0ca0c24e3211 ("mm: store zero pages to be swapped out in a bitma= p") > > Reviewed-by: Nhat Pham > > Cc: Usama Arif > > Cc: Chengming Zhou > > Cc: Yosry Ahmed > > Cc: Hailong Liu > > Cc: Johannes Weiner > > Cc: David Hildenbrand > > Cc: Hugh Dickins > > Cc: Matthew Wilcox (Oracle) > > Cc: Shakeel Butt > > Cc: Andi Kleen > > Cc: Baolin Wang > > Cc: Chris Li > > Cc: "Huang, Ying" > > Cc: Kairui Song > > Cc: Ryan Roberts > > Signed-off-by: Barry Song > > Acked-by: Johannes Weiner Thanks! Oops, it seems that it depends on Kanchana's 'mm: change count_objcg_event(= ) to count_objcg_events() for batch event updates,' which also isn't present in = 6.12. Otherwise, it won't build, as reported here: https://lore.kernel.org/linux-mm/CAGsJ_4whD31+Lk0m2uq-o=3DygvkRsw1uXcPeqxBO= NV-RUXkeEzg@mail.gmail.com/ Hi Andrew, What=E2=80=99s the best approach here? Should we include Kanchana's patch t= hat extends the nr argument for count_objcg_events() in 6.12-rc as well? Thanks barry