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 15742CD4F4C for ; Wed, 4 Sep 2024 23:36:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 750B56B00EC; Wed, 4 Sep 2024 19:36:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7016E6B01F6; Wed, 4 Sep 2024 19:36:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52F8A6B0198; Wed, 4 Sep 2024 19:36:34 -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 2FCF26B00EC for ; Wed, 4 Sep 2024 19:36:34 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id CF4F5140718 for ; Wed, 4 Sep 2024 23:36:33 +0000 (UTC) X-FDA: 82528667466.01.8DFD1B5 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf29.hostedemail.com (Postfix) with ESMTP id 068D012001D for ; Wed, 4 Sep 2024 23:36:31 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Qm4WPx7E; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725492967; a=rsa-sha256; cv=none; b=TzL1UctJeNBm/D7bkV71cso2t02iv+ejNRSvLyRDJvWQyLcJ2jn6dmylwQZAvw0tWush7F IYK98cEZyF12YqojYaZqtvhdOFLijHb6Fb2mst6q88fSUYG3N2iCI+dGuQB1rrKH2gyiCm GpaJX2AL+nDTfpKvTK/5/Hnc7PrqTvA= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Qm4WPx7E; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725492967; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fOa1Q51qe4eSFjqGABixW/4hdYdiQtGL11hyrEMANlA=; b=NbIeGlfhzzZ3Z5Zos8bpluLkBqf7YDU58aN+qZf4Yx+LEpUJnkFYDpWOmZbpcUY965OfDY 9H++1RiscFomBZSY2V/olU9Uin1sIECsTNrBU43PqxISt2Ez9QIU9GCnARx60pq/GoUiDd flzjUAC2peSb+e0W+jty+c5EW5WWt+s= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a86984e035aso35371466b.2 for ; Wed, 04 Sep 2024 16:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1725492990; x=1726097790; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fOa1Q51qe4eSFjqGABixW/4hdYdiQtGL11hyrEMANlA=; b=Qm4WPx7Ej+D3nJK+OUHWXB7t9bv9+uK4645T+MVFzyrJrHcmO/wn1XlzhrS83YEu++ GavOGY84eWlQsxT2uQdlYexvXWLsoyl+QqhYdE0Ephtz+VdeCUp6aGF+z85NeU7v6Sxf HxYOyVghhOBY4yPGlfdfZ1Ee6BXplyINfQ2zpGhmNQFAphwc8oxNUS2A3KtsF0dqolx5 Gterf3l+Vbswe2jtBxOe2bbPmW6Qkepa55/SMUmSqkiDEYmCx+za+1uXexbYt1HeCsi9 J8q5SR2h1WDFMqSjVU/6h6geP+knox/+pb8Nlgzi9tV+/GG3ZD2FhZbC4z4FRHT3X5Sa bIQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725492990; x=1726097790; h=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=fOa1Q51qe4eSFjqGABixW/4hdYdiQtGL11hyrEMANlA=; b=Ebh0Ws7uH5aPf/jEwkRYSrdNB33F6+GLjv2ClnSUF6U8/PDaOAUbNfTuZLwbhWj5dD spDJkhNTu7hi84HFjaqpvlkUfHo8es/BUeUaRuD9kb0EBupetYWUZSwDLCd5yy0CG4KC EhqRkyvhkXcs1tMTUTyTm6VPl+oZuq6wzbGdZ15tk7GiULiTC1tRkY6YEtf/xltW0gK7 ZtufpKjcOYIk6akNSvd2hP9oZSp2Gr9PieaZdpmrjjiB8CjPDZAKYMlD5TFwdPs221eP 0mnnX8Ua2CutwXGpiaucQ1kBB42xH2sw5la77/K8a/ICpjnqDP3Sr/YbC76OTbHv1C2U Qx0A== X-Forwarded-Encrypted: i=1; AJvYcCWdu+Gb/GSEBj3PUucCQdH1sM4WCfQcPEhntA1v/eUQTBG2FMNB9uVnXSbhyzZhPuWUlhmcXBwYAQ==@kvack.org X-Gm-Message-State: AOJu0YwT8k6kH1yw4yRPhywQ/+JUu6nX32X2kzFcFgEdZ3r8WecSalfM zXyzSMpmGX3JV9gOhrBv/RTJaeQRHJGq6O8qBDc0z1Q/8t5oX4EW6QDWB9QcQ5nLzhEfqKuKL8d u4VxfuyCqCvFof4QtSz4pvnYDMR+b3jGzH1ZXhg9PwuivIbRhqA== X-Google-Smtp-Source: AGHT+IHDuuc1NSBZcv5eJMmcgD4W2enzMP+OEXUp/tHe1vBeLVIoJgIUtpVBiUuFO4YpWpSbAoDry8IrbZw74IYvlGY= X-Received: by 2002:a17:906:db07:b0:a86:ae95:eba3 with SMTP id a640c23a62f3a-a89a3823702mr1493644166b.62.1725492989563; Wed, 04 Sep 2024 16:36:29 -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: Yosry Ahmed Date: Wed, 4 Sep 2024 16:35:52 -0700 Message-ID: Subject: Re: [PATCH v7 2/2] mm: support large folios swap-in for sync io devices To: Usama Arif Cc: Barry Song <21cnbao@gmail.com>, 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 Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Queue-Id: 068D012001D X-Rspamd-Server: rspam01 X-Stat-Signature: gcf7srdpmo8pp9qdkxjrdrt6mihroiz1 X-HE-Tag: 1725492991-601757 X-HE-Meta: U2FsdGVkX1+vV5TWj3B+zlHBRC3/3Qo0oAB3JaoChl22q6GMKZRVUf/YnGwBynCVsmtiBUfQ2MIC41hKf6pJQcjyAJyylux9DukD2TbEuoqDvXuuLlqv7Voh8Rf8wz3tJvTOM2XjASNdZ0wrC1IbgKLn/N3PkzbyXbSEqKAcTJWbG9fvlLWnYsQD4CuMIABJB2qXnvoFyTaDEkoeYzJb06NSJbEeSuPS/nNJvwFCmqzG7GWUcD718uwz8I8tX4Xk3IBDaqdvALAi+r35I/bUP6Zb37PAlW9wLaQiyFoevg37KMV4dm9TsB679p9sWJymKP/o6Lz3cjd7lXO0Rt7WYSq3AJTd3zTGpkNBb6f4KKpgAqGT7sukhFCcOj1Az+NdE7xpO+B1C+reXsLdSaQPkQHIcrIYgQtNqntKLtkUZ7LGmVuvMvpoxK4cy5hHEDEyGGVZiUI3i2cQg4yogvuzyl7aHVKxjz+EXrSYk4udifBC28ZdjSamk1dQ4aKwXGgFJiUl66qdpDj6IX0K60feAx//Dwg65U7y/RHAwXSqtcxdiRgeloZpfJ5AW8AArIfiS4jdHZga78KPgNEU0tMV6RXJsae1uGIzzDMOxrpTXaee6/ZBjsI4NWn/JZsRANs/5UHMT7E5lPDBE8/2i2molMeYKoj6nPSYmEqG+rxkEVzeYaON5FaCMAWPLLoqyWJ8kY1KET4bDB3PEC7I4ME/f20f1m3MWyd4iMB5s9yXWqxmM7qAKw6RhDv4LejrK9oCfFHSbRBSJYMqVWf7JpxioCDeY32wV6pgXMHsdLU6z6UmuEKYd0D2E+vcOflqjqf4bUoZadkDyH1VSRmBqTHn84ASu367fi/3CPJiGkuYrTpq0LrngQ5gkMK01kf9k1thVRWcLbvkYGLZKCON0HrVCXRtLV1iclH3/l89Hwa4OUdy11nCFB4g6K6pdslf/PTuc0n5rhKPDDmQg4oqw5d saO1qmSg op5yGnK1GCcE/WOceQXDzLy/fzDRJzZp3eqH64Q3LVLaqHxuTKBfQWB7BNgNApORh4qdFbEnF0h812eZNx8l8A2mlo1acUDcB86nk4KREBSD5JaTfLpIBRZygdd1N4lzxGOKeUoLLx+h6pu/5zwo+MQSl/qTPg3uzow812nMlOX8Lv6KhW16YkNqeBk+wXXhIwZggrl1FbUPE6y8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.029593, 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 the other hand, if you read the code of zRAM, you will find zRAM has > > exactly the same mechanism as zeromap but zRAM can even do more > > by same_pages filled. since zRAM does the job in swapfile layer, there > > 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 duplicated > > efforts while I really appreciate your job which can benefit all swapfiles. > > i mean, zRAM has the ability to check "zero"(and also non-zero but same > > 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 filled > complete pages were less than 1%, so essentially its only the zero-filled pages > that matter. > > I believe after zeromap, it might be a good idea to remove the page_same_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.