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 751E6D10BF7 for ; Sun, 27 Oct 2024 02:45:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81D816B0088; Sat, 26 Oct 2024 22:45:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CD6C6B0089; Sat, 26 Oct 2024 22:45:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 694FE6B008A; Sat, 26 Oct 2024 22:45:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4A9636B0088 for ; Sat, 26 Oct 2024 22:45:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3124381A28 for ; Sun, 27 Oct 2024 02:45:37 +0000 (UTC) X-FDA: 82717841808.16.72CD857 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf14.hostedemail.com (Postfix) with ESMTP id 9A4FD100004 for ; Sun, 27 Oct 2024 02:45:29 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IIyz4N7u; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=nphamcs@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=1729996997; 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=CgagS/O3iJFPk0jh3DCNk1vzjuL5/uReh3FNYc6S190=; b=gN2PdSEHN6vB4S9Ie5JNB4LD3aBTUnEcrS+K/KAaX4AZNNoWJ6bjzI6hEOTZCo+cN/swic Une1q5I2z7gHi09GIAH+bfOp7CA7Z8XxA33vXrV7aOzv9wYRODS0YwH73Zi4qJZiev8gPJ nl0OBoDnAlLvOcZO6UdfkvqIksnzoHM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729996997; a=rsa-sha256; cv=none; b=SJkuZCoKQFaJ0rTBsMbVbiknA7gze1jW8/1lRrs5FDEWNPOZ4RTc6KKi5uG+L8NoAkKJu+ ZDG3F9d7NCdquCJ2HRHBH/BlFX/pmxVHg2P0isWhqzv6iC9ws6FQdJ9DeJ0yDmxKo5vBss oowAHRruBfBHnV9FQwQhwDB1ZpKe6U4= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IIyz4N7u; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-6cc250bbc9eso23747196d6.2 for ; Sat, 26 Oct 2024 19:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729997153; x=1730601953; 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=CgagS/O3iJFPk0jh3DCNk1vzjuL5/uReh3FNYc6S190=; b=IIyz4N7uS3jVFsN1T/9F5yt3pwkcHM4+TMQ0+BIGXMzmxvAcc8BNMbkaZsqjnZTubw bANTM0KBoCb2XCtp2DEHYgNyRDiIN5tWqUIh8UBXh82/soiv8v1lgjEmsD9FD+7JOKvd 5rkLFZiWfrkKGGY1OYu5isLvVikXhULG7BjanMa0o1roUxxw/MQPVVf7DDUxQuCaobui v1K8qMEFZUgONhmElQxbsA/cq0UsLYbwG3PUKKwUrL59e23C17bbIUKqw05yfcg69nEP 14MigN7KUlkXo5Tx+/ObIzwJ9kXmIGSXK+yNI6hhjYjWcbGG+N51E1jO6K83J5/B1nDd KV0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729997153; x=1730601953; 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=CgagS/O3iJFPk0jh3DCNk1vzjuL5/uReh3FNYc6S190=; b=VeO1rgDiwayawTHKzYpetO6nm7W41bfGMj7e0iY4+8XFr8CY8uffxXyCjLHqyK40g9 DVnAKX1kaouNMdI+IYaSfPvYx6KKoOt0BW5W44ZFErISXmYRSf/IK4b1ZnjvCtckWMNl HiM/7sy9uJqvEaIJLSzDNRU5e2uIEGoZgOQh+2f9mztbCgwYrd0pgCORfbtGRRiNdS2B LauXheeKQyT5ObGCtOiMVwni5iQXeMw0WqKZFiWTtTBHNe2/0l5WYDy0Eor6sSTXctUw lwaWPT2x41Evl86RkWOQKB/XbINmWR2pWW6rPgMKXLeeZMy963GsHUmtkdBElcI9BLsM skdw== X-Forwarded-Encrypted: i=1; AJvYcCWRZYZ2ibmuT6aYchh1wYY/RKNA44SNgd+CEieRGr8+cJn3FO3I8w2bOaZa3wdYcYEXSuXVrKCZQw==@kvack.org X-Gm-Message-State: AOJu0Yxh+Eb13LTC4D/nJv4caipPaXryeTziekMdbHRPfnzkJDVc44BQ ihB4bUJPdvn/MSCsKLh4ajUpZuGi+Nb7Ix1GbWG+xtLN7rzEpF9mZ4fNiTquGeu3eiO/TMDNf+c w5zhwgi8m5gmTHLhxYx6CIPyLFPI= X-Google-Smtp-Source: AGHT+IFEhsaeNT9jZrxkEeOGaHktAe3pn15HbGpKN2WloMrpUzXtqAMv81NwMrj0rirhmo7aLJ644QuYCWUrr1EBlLY= X-Received: by 2002:a05:6214:4805:b0:6d1:83ec:32f9 with SMTP id 6a1803df08f44-6d1858409a3mr71809056d6.35.1729997152913; Sat, 26 Oct 2024 19:45:52 -0700 (PDT) MIME-Version: 1.0 References: <20241027011959.9226-1-21cnbao@gmail.com> In-Reply-To: <20241027011959.9226-1-21cnbao@gmail.com> From: Nhat Pham Date: Sat, 26 Oct 2024 19:45:42 -0700 Message-ID: Subject: Re: [PATCH RFC] mm: count zeromap read and set for swapout and swapin To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Usama Arif , Chengming Zhou , Yosry Ahmed , Johannes Weiner , 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9A4FD100004 X-Stat-Signature: jwf9u894k9scbto8879tnnht5u1h8ddq X-HE-Tag: 1729997129-510117 X-HE-Meta: U2FsdGVkX19TMfhMWO7IS47aDWuX7orypYDHz9klbr8RB5A4lPec4pS1CkzLG0AvxNZQ7c+XN1cO8KxmentaSVZu900WnbituKmRJA7OgWf8qALvlGWXgf4GHv+qUxAXaitRRN/badSuWuHO0MbS2qZLWdO3+H4tOl7N156UZPFwo3d82YncEn8A0vuxTaGpX/okVttH3RfqcLoTG4LM+tfHsUyGnSCKUHtxH9RwJMKFz6m5dLB60WCYxTnl7NogFIzLUWI8yeJVtD9/dZFKAvj0Zac05xJDYWYiAaW/ReJdR7HoUZztB0iGf7uZzKwSFdY/RFd0Dg+bt/zggQxD/xHh4p//6iDDZuKO5aS5C/Cu/PsGg8BF7wGb2iUC2u1AMWdrKpzmcZjCYH21xz1Gvfx15K3eMw8wG6e4iiqvyoYq+fFyzHVfVsPIRpTrAUGmxdFBRIhYSCc64jEaZu6OJfKGD/tmXAcWzXUjEtpmJXXpw24cGqvLMNcC9kC/9JmH+NBTCkcZHOItXGoMc1VlCpcy6jvuHawJiouXFrigxZHJE+zu9MAPgbq7CmFie0tInMnQSKlxVpb4Hk1No/PrG+gQU9glNcn4QTXOYbU9ItZuvJJYMOFWmLkbAmnqJr94m5HmE0LUU7lVEv+beF13o+hD5ykTp5N6TFCJ6Nlgcy/+kKg/hZRtXA+DaCIXILxNUZA8Eot6hj34dMsNfx+MpDi8o4+S6IMp8PB+fLb1kRYTjmMmizg4Xjkmv9L7fVyOP5pFIkAfpGtJCBVQGefFwgFWwZHDhsBxIOn2NJ6/s/bmyy/uyT5lBXutdxfmFND8V1cgtn+HCCift5m4UwVfycmv1NuVqITlUHWkAgmZdFBYGcFOW+GrLz+1vVU3GtXWmlFIugvSWfs6zDY9852Ca9PTwNq2RuO7VioYLoxpjxukWO9iFiYapYgv4MgNAdrassqDfZFdF/I6Fl5hedM ozLPEk3b AE5a5kuFkpeEiAPFj/BmTPMuYpp8PlU023kqgt0jObyuYJoXcBkbuI86Fd2rlII2yJXRgzKtDINyd44704nK/D8ZMhQdrj2Pz81HGG8U+VXbcctP+cNa2E6kXAoyG/+65rIwZUF4jF+kvhLhSt6+Bg0Ihva/5ia0sSutdC4Kk6NnsT2oZUPD6BMmNXzbAn5ghNJLnKxU+cFt9M3FFZmKfFh97YOgQvP/gsFyIOYAdke4kqP9zd0Jax7frnj7y8tC9c/39XTNuEMoxU4G73uIGzxMoUBDu9TyX9HYVHJrAVikEzrArBjPtiFdMNFs0OiMtHIQWloJ27yrjW89qpRbB1zeH6zaQuP9hmJbclwN/R3+lKUzyv8hPJRS/8Q== 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 Sat, Oct 26, 2024 at 6:20=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > From: Barry Song > > When the proportion of folios from the zero map is small, missing their > accounting may not significantly impact profiling. However, it=E2=80=99s = 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. I agree. It also makes developing around this area more challenging. I'm working on the swap abstraction, and sometimes I can't tell if I screwed up somewhere, or if a proportion of these allocated entries go towards this optimization... Thanks for taking a stab at fixing this, Barry! > > We have two ways to address this: > > 1. Add a separate counter specifically for the zero map. > 2. Continue using the current accounting, treating the zero map like > a normal backend. (This aligns with the current behavior of zRAM > when supporting same-page fills at the device level.) Hmm, my understanding of the pswpout/pswpin counters is that they only apply to IO done directly to the backend device, no? That's why we have a separate set of counters for zswap, and do not count them towards pswp(in|out). For users who have swap files on physical disks, the performance difference between reading directly from the swapfile and going through these optimizations could be really large. I think it makes sense to have a separate set of counters for zero-mapped pages (ideally, both at the host level and at the cgroup level?)