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 A43B4CF9C6D for ; Sun, 22 Sep 2024 23:57:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 88B266B0082; Sun, 22 Sep 2024 19:57:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EC416B0083; Sun, 22 Sep 2024 19:57:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63F1A6B0085; Sun, 22 Sep 2024 19:57:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 418D16B0082 for ; Sun, 22 Sep 2024 19:57:41 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A099240FCD for ; Sun, 22 Sep 2024 23:57:40 +0000 (UTC) X-FDA: 82594039080.07.36E0038 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf23.hostedemail.com (Postfix) with ESMTP id C87B9140012 for ; Sun, 22 Sep 2024 23:57:38 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bk2rCRjd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727049424; a=rsa-sha256; cv=none; b=GULxqB+s8YPd4Cj0wUNEiawJVD0Qnbo+h9FkvyIG2npLQ02bAJolbr/e1oYvgTa9rfwA+T pMxqIom63mZ8kGy7TtPFQRhKBQHkEAj8YcgecT102FRmm47FTeFEUXP+ZGzYQuerbAfrc/ HLUplSGiG+1xQXugJ4nBxW6s/bZeUNc= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bk2rCRjd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 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=1727049424; 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=CAD1Nttxi1tuaZ4G5Nuq1uTbsGqc46vm2EtT7QAKfXg=; b=rAGAKN4keSdLVFwSVk9isOi8edlszCD1cQz6LILvRm7D7+e++IbvAjobA3iwq5HlvQRKRT TzKnup1RSf/bbB+qWz7iftIoq6j6lvvhds3mh0OscDkSwfFGyow4LiVQ1e9fWnh13r9Qp7 ii9svYj/7g4uyILBnIkNTjRQ1AzqhSY= Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-502b6e2a0acso1305381e0c.2 for ; Sun, 22 Sep 2024 16:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727049458; x=1727654258; 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=CAD1Nttxi1tuaZ4G5Nuq1uTbsGqc46vm2EtT7QAKfXg=; b=bk2rCRjdZ+lG0yVWjGJUuTaAdPa/4sFrM8Nyafo8q9aE1UFCgtziALmifWBVq1qOBn 3aC+FBpVopXh54hnWBWIB9gg3Or9R6YisapVQatp10YTmmdAjjl8/WBugwA7lF+OoLNp +npyxb6DVuQkxNM60lP6cuJMDop5/qyVUiW2zLy1vZzsAlhzz+aepB47lSGb2dKy8JSv U+8x2/J5hW94oNGqJtR2DlGQmGEy+yzZ6T6WW0jbNd+jaV8WvXfoPuNuxLRWdkNgLtLF aLlRxIA6sWvgZW6l8kwuiPfk1SsLy/umv2QKOAHeNqzCZgtT2uMwEBgCehMpe4ZvFiIN NMqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727049458; x=1727654258; 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=CAD1Nttxi1tuaZ4G5Nuq1uTbsGqc46vm2EtT7QAKfXg=; b=blvwVR3k2Ag1pmt//NRiIRVBXHa/jfjS9o/3KppaoL+7z1k9sZ1AebQoedcmevcVJA M+vsr2vcCm8AGXm03oXGozFU05NOTpMoNpf6i1bOHbGIledh1cb1rLIaVPbwByp4MyJW /9DJvPrEYpWggiF+07S/3GDO5rtQGix/p+QdwDqB0kyJTqaJZWoVxKiwn03R9u+CDukn eYA5N2XNS11fsr0CCt5wvCsOMBKscbkLNNxFRPBHAbu7lpvxJaWwMVNBBwjdPpBwU8gN 6DtkGKYp+uSVlH783HlCH9XcfbEd4tBBg4tuH0lQn3dSPMNYP7t7O3TWZyGPoEdhvvWs W4bg== X-Forwarded-Encrypted: i=1; AJvYcCWF9CGXk3kI3k6G54G2W/wrlObzvqCcv6sUxh/TVLwXEK9jUH26PNaGbm7kJHNTSCQM/Ewi9VDeJw==@kvack.org X-Gm-Message-State: AOJu0YwGPSI7XZ8KSE4gPOU3QJII/DIV7ppVgx9w49bAzJ2K2Dzb0O+F LP9CDRmf6lGyAPTGX+Z+YLfOGWqC0PCkS+uiVaC36JPrk1Ub56qjHLFE21yb8NfmjB/Ly6mnegY PQiPhhHUvXhvlongwMYhcOss7niM= X-Google-Smtp-Source: AGHT+IEqkLE6FvrpXESDtzTTE4utfGcHu21lxH/e6PT9sOSdS7qUrgSqHOXjoAZkp2rkESz9wImJXQXD6+nyNnhGbaY= X-Received: by 2002:a05:6122:1826:b0:502:6d58:4501 with SMTP id 71dfb90a1353d-503e03c1293mr5952762e0c.2.1727049457758; Sun, 22 Sep 2024 16:57:37 -0700 (PDT) MIME-Version: 1.0 References: <20240821074541.516249-1-hanchuanhua@oppo.com> <20240821074541.516249-3-hanchuanhua@oppo.com> <20240903130757.f584c73f356c03617a2c8804@linux-foundation.org> <94eb70cd-b508-42ef-b5d2-acc29e22eb0e@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 23 Sep 2024 07:57:25 +0800 Message-ID: Subject: Re: [PATCH v7 2/2] mm: support large folios swap-in for sync io devices To: Yosry Ahmed Cc: Usama Arif , Andrew Morton , Kairui Song , hanchuanhua@oppo.com, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, linux-kernel@vger.kernel.org, mhocko@suse.com, minchan@kernel.org, nphamcs@gmail.com, ryan.roberts@arm.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, hch@infradead.org, Hailong Liu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: C87B9140012 X-Rspamd-Server: rspam01 X-Stat-Signature: tq31mh1ubrqeirp1hh6npmqnd8qjay71 X-HE-Tag: 1727049458-475527 X-HE-Meta: U2FsdGVkX19Le5Zc1RiOvTs4F2gJLMhEMZu1EyczqX9Tf90kDzv4WwPAdH7XW1YkFOmq4JPo9g/UFk3o0CCW3HxYBacrP1VLLb0pGJ9LKczrY6acpbrkImIAvqFOV3ELjbF1XfmqgrFElCER/Ubxxw1QcbFW0QMXU9zOLmCx/foFsLNEpWsvabC8Mm0Rg3emahSESh7JaJ7RXjN/eL199huwF5ORJVdjCneGew8mOnMI0wHBpw/RWw51sV9+R582WVVMVWnjx2wyUtFIYDoqkJPamFKMuj6OuFU1bod7Z/2Km1/rlKo1b7eoN3dtMvzQVu/4ybT/Lsms0z93/q7WuZDKbDvlGZeOPo0zv3Lt96cFG903m9m4oKJvLJNM+JmMUDLmfB+FapVa4JFp8dCFx+u2QJ6EunZ4PwI/fex3ZK9rRVm/4y5VNO2jM6NdHVAdvtU2CQkzyksmGJaU48cmhI7/ZKsgiDkarNl/94l/9XtHyvl9btvD15bhV31enue93xrG4t6uIcoPotCzbDryrbHzeSV/7f/WQH+0u4bnl7jFVhMgSVZzAR8/QgYCvtb8CziBTs3HelVhu17A1iG2PSPCBiELBO8N903p1XSFXEwWodMRxdZVPuO3cjyEHq4mVkgw3TXFXQwlEFP71Rqxl4SqkllSsV/vjfOJlFGlI3ABV2GR5ldEuU5w2rxKsQBZMqqR+qHhXh4dC0zUsujX+NL6gu0HhUKqnYWRMPrfscwGST6MwTSUZSjBAne7hdYCXoaNl92RFs0ezcAo+FGuXz85Evhj6FvE2PgVSLNPZZpgHU66NvcII3/Jafoa57KIYpGKJDzn19XV046U1ACCaTAXrkICf8pKxEw/HFbDnO1kB1kCihCdqjNuNvGDkn8tOhfHdepslegeXxlV1u8WWA8kUVg2jxCxLZlg+uzsyyXLKwAr1uEA61eyhZvAXQass7WqEdLR51jnu/vpf4A Zvh89IiQ 5V+QDMYxaJjrob7M1NfGxqzUVB2EiFuZH0NkKDMeh/KD4066nwLvInsiakoFxjz+mA3b59UK6OdAu8PH/pwBbAGl8WNGiuEE9lXu9D7WVQYpgtmGf45IY8/8mvZ4LUoM2jovymYWPROLpX5Y8AgH+IcU/hCEp1Jzv46lIJEI/uP2Hpwb4KBwVcaaQA1pcdzHA9oI8JY7yuFCbdiU2WRQFrgzIwWkIoXqh0Q90lJ7HNtsVgh9DxXH+jb8tLk6+Bjk6FLNeJIbbeX/i4HP8IzkeXkRImonyoMEjlDvZrxwazVZcfLyhomAf37dtCoNxlt/g8j7Kcbg5sjdtsCh8EhhPcgLHgAbR/2H7xLpFY4vPHqqd+I7kNqZJNmrztKd+thynfVO0w00vCFwJM+Y= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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, Sep 5, 2024 at 7:36=E2=80=AFAM Yosry Ahmed = wrote: > > [..] > > > > > > On the other hand, if you read the code of zRAM, you will find zRAM h= as > > > exactly the same mechanism as zeromap but zRAM can even do more > > > by same_pages filled. since zRAM does the job in swapfile layer, ther= e > > > is no this kind of consistency issue like zeromap. > > > > > > So I feel for zRAM case, we don't need zeromap at all as there are du= plicated > > > efforts while I really appreciate your job which can benefit all swap= files. > > > i mean, zRAM has the ability to check "zero"(and also non-zero but sa= me > > > content). after zeromap checks zeromap, zRAM will check again: > > > > > > > Yes, so there is a reason for having the zeromap patches, which I have = outlined > > in the coverletter. > > > > https://lore.kernel.org/all/20240627105730.3110705-1-usamaarif642@gmail= .com/ > > > > There are usecases where zswap/zram might not be used in production. > > We can reduce I/O and flash wear in those cases by a large amount. > > > > Also running in Meta production, we found that the number of non-zero f= illed > > complete pages were less than 1%, so essentially its only the zero-fill= ed pages > > that matter. > > > > I believe after zeromap, it might be a good idea to remove the page_sam= e_filled > > check from zram code? Its not really a problem if its kept as well as I= dont > > believe any zero-filled pages should reach zram_write_page? > > I brought this up before and Sergey pointed out that zram is sometimes > used as a block device without swap, and that use case would benefit > from having this handling in zram. That being said, I have no idea how > many people care about this specific scenario. Hi Usama/Yosry, We successfully gathered page_same_filled data for zram on Android. Interestingly, our findings differ from yours on zswap. Hailong discovered that around 85-86% of the page_same_filled data consists of zeros, while about 15% are non-zero. We suspect that on Android or similar systems, some graphics or media data might be duplicated at times, such as a red block displayed on the screen. Does this suggest that page_same_filled could still provide some benefits in zram cases? Thanks Barry