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 B1F85C27C55 for ; Mon, 10 Jun 2024 12:18:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4AB426B0085; Mon, 10 Jun 2024 08:18:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 433456B0092; Mon, 10 Jun 2024 08:18:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2FB216B00A4; Mon, 10 Jun 2024 08:18:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 11DCE6B0085 for ; Mon, 10 Jun 2024 08:18:27 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B2B7840F91 for ; Mon, 10 Jun 2024 12:18:26 +0000 (UTC) X-FDA: 82214881812.11.441CE17 Received: from mail-oo1-f46.google.com (mail-oo1-f46.google.com [209.85.161.46]) by imf22.hostedemail.com (Postfix) with ESMTP id F0DC3C0012 for ; Mon, 10 Jun 2024 12:18:24 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YzUvNKcp; spf=pass (imf22.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.161.46 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718021905; a=rsa-sha256; cv=none; b=B6b2dhM8SK+vhIkVJ4LzDnlnsKffnqmjIbRIvc1VZm2IA73xW66BrdHKMu+KcE04XbRZBx 2Cr/KvmUNg+jRVbhghiNfiXQbaR+bzgNQyHHskD7auVsAX/1zJDVNobT5Jtb6slRNZd2Q/ Dqq198E3dU/a3hEVLlDFJGbHkDT3Wfc= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YzUvNKcp; spf=pass (imf22.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.161.46 as permitted sender) smtp.mailfrom=usamaarif642@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=1718021905; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=0+Az1PpLJ4JYTtMedJjbgRRlyQLWkppyc96i5melFic=; b=udD1GxQbyA4KbCvNNqZxNMgs1aqtyNVnc2v2AZLWXDKU9NroLFOz1Kq7JYLIHl0/+L6Krr KNMTTlHdmCg/AFa60MG8e0FF0kULFcQ8TaqfK2Ixzx+jhlA/19gcWy41LGkuYVzTcnoBNq xeRAYB1Pn6MY/kRleSzyXd9Y+iJLqv0= Received: by mail-oo1-f46.google.com with SMTP id 006d021491bc7-5bae81effd1so835971eaf.2 for ; Mon, 10 Jun 2024 05:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718021904; x=1718626704; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=0+Az1PpLJ4JYTtMedJjbgRRlyQLWkppyc96i5melFic=; b=YzUvNKcp9qoeHxaAurBAnLvJsHr09jZGnvPAWtduiWWQUG9sctOZRpKelMw+l0M15g 6yo3JX7uhMVG9xhnVwvtsROGkVRpxXB5nMZHUcQHP86yRegsb51rFBLN/0zrTCAo84sv Y1Q5dvzUqHOc8mqjH5/ZZtIEooGF1GCvEPhnary8NlagolhJvh7QGVALjT7a9SWB5RGV eeso+hW4ISdyfhLtFwf2NtVUiZeFU1TjiC+9c5sDsVD8DT5IXJaN1wXYd/MWCfPPwB0d 0ikOaeBhQFLWCv9+iPpUh+mihgX2/fm1m65t9ls0alvxtk5Att8lKoeq5oXhZ3lTMGNT YKjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718021904; x=1718626704; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0+Az1PpLJ4JYTtMedJjbgRRlyQLWkppyc96i5melFic=; b=b9z/MY2IwOJ5P3ZZf58gfOzGejQzFB3kA/hO27QeZKIbRaXFvc4/vj5x3OUTQm22XH l3EMoXLnh7SpyglEKVtnDEzMORc3kGyI0PXSLw5G35snPDRETlZeuDpeJW0h4c1kfJyQ hibBxabF1NmqMShF1jHdbOCGTEUPTHf7Jrhnw9er3lDoQUsMWUeAMCu/z9xirCqaqE0V HVVV7QUktw/LPHgA6X1EyWXOntvbI5wX3CqdmissdArF4+aFSEhXEd55b9YmXL/uQL6O dAj55epZNxv9Sa0h4CL3HBEfeV9FJtfgLKriTYPbtxOZt4gNgeJD1bj3ryD0Uy2kzRGP 194A== X-Forwarded-Encrypted: i=1; AJvYcCUtU0XscPyjqz+RnKihPcHliQVZIaGNMcQ1iLBC8qOwlh0lGIuOrO7zSo4rwNSIN8U9473/0+QX2AZXteBt0n14fEk= X-Gm-Message-State: AOJu0Yyh0/WiDZ3E40y66cZrIyxsgR+yGTXQO+aSaNaU5cr+fynRMoPJ 5/+YgGT3wsd1yzr3IwXqR6SRU89Xwwfd2vVd506YcgFXaMtme4mt X-Google-Smtp-Source: AGHT+IHlGKS8y91VhGXHAROeBpYgpO4e/NBHK33a/DUHtG9u+8/tE43i3a/RyUN7beMURh6JEM4UUQ== X-Received: by 2002:a05:6358:63a3:b0:19f:4d27:fb77 with SMTP id e5c5f4694b2df-19f4d27ff52mr491142255d.5.1718021903745; Mon, 10 Jun 2024 05:18:23 -0700 (PDT) Received: from localhost (fwdproxy-ash-007.fbsv.net. [2a03:2880:20ff:7::face:b00c]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b063821c95sm32331886d6.96.2024.06.10.05.18.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Jun 2024 05:18:23 -0700 (PDT) From: Usama Arif To: akpm@linux-foundation.org Cc: hannes@cmpxchg.org, david@redhat.com, ying.huang@intel.com, hughd@google.com, willy@infradead.org, yosryahmed@google.com, nphamcs@gmail.com, chengming.zhou@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Usama Arif Subject: [PATCH v3 0/2] mm: store zero pages to be swapped out in a bitmap Date: Mon, 10 Jun 2024 13:15:58 +0100 Message-ID: <20240610121820.328876-1-usamaarif642@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F0DC3C0012 X-Stat-Signature: z95ec5we7jsf8wui335tcdc8cq8u6fmo X-HE-Tag: 1718021904-444876 X-HE-Meta: U2FsdGVkX1/CrCJIeGP7jHHOcHV9TDvkEX8pAEJXWd6z/ynxXLMWn6h4RiGGfqctogtW3ynOsMrFM64J/SLEM572bK09J9FN4qP4RrWiw2F+Odyyksr4WGUpGyPuEORBQXS4poXVC22WocD37fjdRKjfuh9IvJ+S3E9Lw1VXB4zG1uvXLc/JQRkZ3Wppn6El0Q5B4CpQU9bLWXkA1eYNLApRoBcd9B8rz6lU7Mgr9oEuJTzGFcndf+tFhNvbZmHDmNPclMQYB4tcKb0I/KrLBJe/BiTZU59jpfpCcOcXaxXTZ+7cHCv4pIiVnpBbz+UKxSBFkUK9RQcooIzxlhO8fmQ6NuPXOkVwI/4QEHxoUHN8NpRHnexP6BskRa3rrN3UxzqmT/tNX+oWhfgt5xK6og7N+g1PEx0K/UUq7wyk/YPoUpQOijrICfc/ilIVRky9xPMYKdWK6R0hVh8TCFW7TlfSXahi1ssA/52akIcd12ubQbGpmvFww9jArIbxLPJ2Lcp+iLzVR2XQeCWrmQ8xzQlinGuTWyhXFU4+taSPl/Zaw73QYemKy/6E9rejLtlb7nzYCddX46eqLD1J/f2CebPBv6k7usPCTBCX/PiX2LxaiRwmuPZKAf8frlw0j0PPDTT7YGi0oRkP4/Rn7BacnudgQB6EKRrlBwcWKag33+WblshCrrIKia+9vrqhzJmhJcujRfKiFIVQrMocPm2NYrPYJqyO4VbxBT28g1qVfnUXUgrahJB9Aw9M1E9UGOYsELnUUgfjP0p+Ls5GV+iP6t0ud0USdbTayJz7A/x/ThDDGeS/Fm/A46rbRdJ1aRHb55kwuFN6cN84wv1Q3e6j1YA+I5iK4g8WWy0mzr1q7xWO7nKsokAsLbio5V/55tXHmFVnlSU3ZEpYvICUoGgHpcRmF9icJrSDuatHbUXJNxXHHSXNPYIAvrVG6izDngFZWOYfXgHDxMvZ9BQYH+4 dsm7hn1/ A23OKu6yVatgVTP0tY68kwBYX3F/UTEJ57GSV9sP2bEUaVRu6+jye3AvMFMif8VSuanfj8clefDzBllYpDhgCIMlvSGobUkKuyar8DecNmtszuZ6o0FHlXNjug8waDGEzd+oUmSAUC00MPKfqk7PcYXIvTZ1D1vWzlGOFGbjX2z+PBrKbNfejlpVhQDst8NGuabxwKe4zqavATBtrT0Gb/2NsEZkcXxGTvDXemVbvnY4h4WnP1vASb6S5RnUsvOY4UzVv/TEsb4yEAhpBeYEaYix/MYR1eWNtNv4cmelz25JnV93oIrb0USJzOBvfqLbxB6VHT8UXM4RIfyQwzMtRqeouPnOD8uI2+iAgZgvT2k9b8hrTf7peVgGsOWMJYRW3TAruLdA05TxWT+Bek4cV05k2C6IlNSijBLvFynU4sM8RJZX/drDuYsVPeweNPrWsIU49OT/ugWri7C8EdgTyWuUdp7t+W6UinAQB 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: Going back to the v1 implementation of the patchseries. The main reason is that a correct version of v2 implementation requires another rmap walk in shrink_folio_list to change the ptes from swap entry to zero pages to work (i.e. more CPU used) [1], is more complex to implement compared to v1 and is harder to verify correctness compared to v1, where everything is handled by swap. --- As shown in the patchseries that introduced the zswap same-filled optimization [2], 10-20% of the pages stored in zswap are same-filled. This is also observed across Meta's server fleet. By using VM counters in swap_writepage (not included in this patchseries) it was found that less than 1% of the same-filled pages to be swapped out are non-zero pages. For conventional swap setup (without zswap), rather than reading/writing these pages to flash resulting in increased I/O and flash wear, a bitmap can be used to mark these pages as zero at write time, and the pages can be filled at read time if the bit corresponding to the page is set. When using zswap with swap, this also means that a zswap_entry does not need to be allocated for zero filled pages resulting in memory savings which would offset the memory used for the bitmap. A similar attempt was made earlier in [3] where zswap would only track zero-filled pages instead of same-filled. This patchseries adds zero-filled pages optimization to swap (hence it can be used even if zswap is disabled) and removes the same-filled code from zswap (as only 1% of the same-filled pages are non-zero), simplifying code. This patchseries is based on mm-unstable. [1] https://lore.kernel.org/all/e4d167fe-cb1e-41d1-a144-00bfa14b7148@gmail.com/ [2] https://lore.kernel.org/all/20171018104832epcms5p1b2232e2236258de3d03d1344dde9fce0@epcms5p1/ [3] https://lore.kernel.org/lkml/20240325235018.2028408-1-yosryahmed@google.com/ --- v2->v3: - Going back to the v1 version of the implementation (David and Shakeel) - convert unatomic bitmap_set/clear to atomic set/clear_bit (Johannes) - use clear_highpage instead of folio_page_zero_fill (Yosry) v1 -> v2: - instead of using a bitmap in swap, clear pte for zero pages and let do_pte_missing handle this page at page fault. (Yosry and Matthew) - Check end of page first when checking if folio is zero filled as it could lead to better performance. (Yosry) Usama Arif (2): mm: store zero pages to be swapped out in a bitmap mm: remove code to handle same filled pages include/linux/swap.h | 1 + mm/page_io.c | 92 +++++++++++++++++++++++++++++++++++++++++++- mm/swapfile.c | 21 +++++++++- mm/zswap.c | 86 ++++------------------------------------- 4 files changed, 119 insertions(+), 81 deletions(-) -- 2.43.0