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 A8B33D13592 for ; Mon, 28 Oct 2024 02:32:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 327166B008A; Sun, 27 Oct 2024 22:32:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B0946B0093; Sun, 27 Oct 2024 22:32:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 150CA6B0099; Sun, 27 Oct 2024 22:32:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EAFC76B008A for ; Sun, 27 Oct 2024 22:32:30 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 537D9121C35 for ; Mon, 28 Oct 2024 02:32:10 +0000 (UTC) X-FDA: 82721436630.12.0BE968D Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com [209.85.221.181]) by imf22.hostedemail.com (Postfix) with ESMTP id 76567C000F for ; Mon, 28 Oct 2024 02:32:00 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XRxwistc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730082620; a=rsa-sha256; cv=none; b=gf0yVuqIU8LpIyF4L9U/DXaJ3ysj7VyKBuaUh8ySW4Lsa+TLkX98e+3gAPKfuMipdgLd1N zvLy6D4P+mycMs+aEug0ULAljnKGeYf6kOd6sZGhNYjL++ZH6WfSNIFELcIt3rgLzZyKB2 ayvsJqnD6T3M+bWf+6O/z8GNOVe/nnk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XRxwistc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.181 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=1730082620; 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=kRU46fFJSWTvTE9azsOVFdvCcZhQWHNPT5RuN/5wiCc=; b=P3tz+gmAovyy7nZkIZCgt1YyctdFYqjlS1GMKpiSLAetvji7jqiDg0OVm27rhltHwZfpEg /xjicxiQ0wpNmC1hekhzKGsbWdg+Olu9mefM7ffoj1IyrCg3kcwzIT0LpQe6fZp6GmrDQX AwW3xjS23uXdlG4jSuYtEEflup2mV2A= Received: by mail-vk1-f181.google.com with SMTP id 71dfb90a1353d-51013e05707so458692e0c.2 for ; Sun, 27 Oct 2024 19:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730082747; x=1730687547; 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=kRU46fFJSWTvTE9azsOVFdvCcZhQWHNPT5RuN/5wiCc=; b=XRxwistc/pVnm83w007ZPCY1DgVeBxxaA48YEcZadKazz5JOf/uYXVgwHNVPTU5mjQ Y//+MLAdLebebSXDnpgLsdWdD1nXfCiS/rr9FgLyInZKNdzr0O362aWdQO8d2GO5rc5v brUvRp5INsEG5RTO5FNoC7kjX/67GHUqQe8mpqaXCYShVrpa70PnQTfM/IiXHT2H3Pyy Y5knjJUHzlKGb0ndyHxBHziTron3UI3o730sxfbRcKi6nf0pYZoKaycqNRz4lXjMsJUr UGGk+hsFs9XdJiZiryArPuT+JqRvXgfv4fu/RLVkOTfcKFH/Y2Yhe3f10wXe/HvwPEor iF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730082747; x=1730687547; 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=kRU46fFJSWTvTE9azsOVFdvCcZhQWHNPT5RuN/5wiCc=; b=mFKyGaEcPZ06XpD756pJn6vthe/5fkQ29Kxfx0rPDyqhE8jLG96ZmcOYuapRRPG4gO hepJyyF+YXcCS+ra1+iJ/f5WmVWPOx0aFrUBQ52gttCZkrZQyYhkXVpoBZOPZpAu3Xjk WFE8m4EvxvOtY/qDuYEot78a0xk2bxr6p+OHGZCweexpucV4bPnkITxgjw1c/O2PG4M3 dwsbYEBpizG9WTHhH6RQHfulZ/5k5DwI30F2uQImxnykS6O5W0UBOjUJDrmLN1HHgllg PyPMZaSVCmS+xqpdNqbCBkt/cs8gF+CKl4/Hf9LKZRKWxp6IE9pqpnX38SaqUagt2xTW 6/gw== X-Forwarded-Encrypted: i=1; AJvYcCWRI1tInk/WG+3ER1cMQeJskocpCZfBPOhO+RDmNliBJupHqdCnhteNqElQIxSM4QT/7ijGkd3yQA==@kvack.org X-Gm-Message-State: AOJu0YwzBMYNnOCr+9Tuc7lfXZ2c/ntJqHlDKCy20dTKHwGKZwJY4wwq tNAmd3W8H+GRka6mtnZynvQx7+IqV6eM1h7LREv4nELwLXrPg0OnK8ozD34YjePEaKhA9ywMXlU VBVLq1nNUL6+Xv0oWx1RZVcEj1f0= X-Google-Smtp-Source: AGHT+IGAKGiQtxNNjWP/suVkwlm9F3CfEs6lSxe8RO2adHAovmGXLEAuKHiz6aysVLjsKqnboadCYmweD4cQxJUO5WY= X-Received: by 2002:a05:6122:1d8a:b0:50d:4b8d:673c with SMTP id 71dfb90a1353d-51014e9d0b8mr3266190e0c.0.1730082747482; Sun, 27 Oct 2024 19:32:27 -0700 (PDT) MIME-Version: 1.0 References: <20241027011959.9226-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 28 Oct 2024 15:32:16 +1300 Message-ID: Subject: Re: [PATCH RFC] mm: count zeromap read and set for swapout and swapin To: Nhat Pham 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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 76567C000F X-Stat-Signature: azhxpq1fbuyd4e7ww61icj7es56yoboo X-Rspam-User: X-HE-Tag: 1730082720-816420 X-HE-Meta: U2FsdGVkX19v3o2TN51j7G4Srwlvex+GS6T6c7HfkzdXIXqxLATmJcyyiAA98OMIUbbHEae5kjiJNk2UnM8ZozDzAEdZPYq8Ta28OnU3vR1ZYwwWnUj+5hUSJoJDTiunwxlv1iNfMc79xFQN1I2coZJZCShry40gUF9Zfnczk4SzbX46PcWuVBBXSYy/jONoKvGxPRPCg+xHiKGNh2nTIQOWYv9LdYsRg8FtCnofc5VGQ/6iKzSvm7sqXuDY+0s52yB3ihgacg7G7pPFc8gWI8BjoBlSF1FNIxZrMlGsHyPkjjTPldpOYBYqWBVpJEbgxZo+LnpAkxc2/ttLCM7NL6B/PSSe9XAnY/xbnxmLUfvSttz2wJfPGRm99e7bhba5YAeNHHYHeJNYrq9fb6D37PaLsRlUtmlH2Jnh0JBcA003rWw+bCvS/jdK+BACs0HqHeStWTVPUNV/dLZkt6CF6qCmrAxNgHx1tGTZikmmWzsAd98344zu1jJjUB+Ns2JDa0Hr0xNXtR46PaUkCb9llVt2AzFgW26f1io70I2lO+jq8RwUUSK0grg2BCRXvqrkMHC+1lHIZYiKhT1YGI2HGoUJbiyrujnB8xc4RAGqBwAQoTYBUci0Z0EWdL8lWXupk8RMxTRWibe925SkLAypM4UzgWyP1H9Xot1XqBgiN+QLpFWQxcQZShs95S1vLVvD7eZcg/MgmoSsSN249OSikmp3cQJnJ3Bxf+6BbB3PapZ3MXfyPRhkyNHoPHb6h+8VZ+CqxXRraF+9aLJI5HiOnW1VTSvRahHiqDaRngmZmDcKfB+UpdBmOsKIBURvzzZygKokw5wFYpZhuS/e864oN68khr0j6xbs/F4RqQqE3/F4Il1+JCsqUILGor6e212DqAzHLe+HhEH8jT0uQyWh2s1z0uwf7kZogHyIhwoN5OP3kEWNmnZcYZIRIBTJDgwloP6/fIqKU/SJXAsypix q8zxkYLM R/FNzgRbjkn20+d2ZApim/rKavMUissgpIOXlAWUX2Z9Efyo/YsQEN8hHlz3+EeZrXYgBa1r36J/Ss6PN77ABDrSCOsY5RjxTuR0VzLDaUaAqIx63KyK9t3601l5AHBQ98LytLPwD9JiQckqgf25yWRQmv46wsy6S+Uxa9UAi5AZ0vbYzu8vC16pdHtlNIRdeS8jA/VdEGhtJkLtAgOLD7trxOt5N48lqGDjQKE94ZkuMiggLER2Tcwzv8UT4r1ZGArNb71yUO9ia470cGNExssaWk2O2J9mLcInK1x5mCYQ9ETbsluE+61hGJgTW44Bv5HndaTyEFGOkCOytM2C8W4fsms5s3kVrAu56AEKGsu2OFTzXPYot75SAPw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.001450, 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 Sun, Oct 27, 2024 at 3:45=E2=80=AFPM Nhat Pham wrote= : > > On Sat, Oct 26, 2024 at 6:20=E2=80=AFPM Barry Song <21cnbao@gmail.com> wr= ote: > > > > 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=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. > > 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?) agree it is better to have a separate counter for zeromap. then it raises a question: what is the proper name for it :-) zeromap_swpin, zeromap_swpout seems too long? and zswpin and zswpout have been used by zswap Thanks barry