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 04A28C54756 for ; Thu, 22 May 2025 09:03:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 75D1E6B0083; Thu, 22 May 2025 05:03:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 70D0F6B0085; Thu, 22 May 2025 05:03:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FBFC6B0088; Thu, 22 May 2025 05:03:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 439396B0083 for ; Thu, 22 May 2025 05:03:01 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C557BBE01F for ; Thu, 22 May 2025 09:03:00 +0000 (UTC) X-FDA: 83469954120.05.150C208 Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by imf12.hostedemail.com (Postfix) with ESMTP id F005640003 for ; Thu, 22 May 2025 09:02:58 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=samsung.com (policy=none); spf=pass (imf12.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.171 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747904579; 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: references; bh=TTwizJiM5bEY2+cJBy7a/nRt7RRcaRggjKwDru+25e8=; b=2rVdJHsBjSOwU7xjMdDmjoCXzHN4/GVXqwB2793YWQQWRmRZkizu8zShxO10mUxaVx8q93 AD87rqXrADn+KysIaQpUL1kvdf5NNdhMmg4MT9qzQ7q4yyR2lvK7lz9E6PD04DL4l1hWr8 M3Dof2i7qRuZUV7pAIbDf4wJidUQOeA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=samsung.com (policy=none); spf=pass (imf12.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.171 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747904579; a=rsa-sha256; cv=none; b=sHuzT3xGuCyTsVhsKQEQwmVpw45V78ubaHb6cjYrEEm+h9jDVgDVIRSAAAK13kabvGeYFa bEq9Yeii7EvtwTqsWEHtc3KGjeqmZBA3WEJZV6e4+Lq41ChXlWGAOK0llPDJucur1LpNcY DGUpC/9J7srtKl7+inQOL4nVdVL1ss0= Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4b32PV1rhnz9sc4; Thu, 22 May 2025 11:02:54 +0200 (CEST) From: Pankaj Raghav To: Suren Baghdasaryan , Vlastimil Babka , Ryan Roberts , Mike Rapoport , Michal Hocko , Thomas Gleixner , Nico Pache , Dev Jain , Baolin Wang , Borislav Petkov , Ingo Molnar , "H . Peter Anvin" , Zi Yan , Dave Hansen , David Hildenbrand , Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , Jens Axboe Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" , gost.dev@samsung.com, kernel@pankajraghav.com, hch@lst.de, linux-kernel@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, x86@kernel.org, mcgrof@kernel.org, Pankaj Raghav Subject: [RFC v2 0/2] add THP_HUGE_ZERO_PAGE_ALWAYS config option Date: Thu, 22 May 2025 11:02:41 +0200 Message-ID: <20250522090243.758943-1-p.raghav@samsung.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: F005640003 X-Stat-Signature: te88yfmqet7a9d3uppq48pefhep9b9wg X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1747904578-584399 X-HE-Meta: U2FsdGVkX18N0nvS8Uug66cab/dGlgpk5r0wRPS7jeExsOGVM4FB40QAAsaPdrMQrfLaxazpEr+FmZeYGSbZjArRoUORNlJwqRA0WO0UVTJgLpHiBeJCzxndRJYhrRPFUXakbG54sYR98Cxw2ymgFd7VYQsMD2XLlfOJ/RmVJV5/WyiYqEGxYTRWPHsaDqccJYq4eJlWIc6PtyW81ONQ9982zTMVuu7y/y+nrCxsRLKpieOLwdnprWph/hNCYjan0RA0113yrm+N8zHO/dgHD7N4mmtQUPWSHMa5jZqI0EMSn4GmX99ca1YoaeBIguLizFKTnzj3Iq/ssfoWZPNEAFtW8L3k/gsGsspOQATiCzzMeTjyNG8zjQG8Gqxog+of6GkVd5nw2I7QVFGuWhgaaX5I8f01E87p5mP12BaBNHOe+/Y7pQ6t6dWpLsHTIbRYLcLTVtbVkx/MBd1eKMboXMTZ4y7b/R2yWgPW/pxkgra7otmvmnUvpG/6zVh5seQ5JKJSN/3tFsHdqpoWH8MyVNBZfIMSdxLCypGX6y6RtjVj1FXinhaZTa3tziUblIF66rszZKRDoXDw58NQBJmXWsABqzo2+h1aJphEr5E3s9DSy5B7lGG3ZCbm4P7HDKESPkf64x8dxE34gR4xGM/GQ4KeD31O43AlIAjQF2yjNgVG7O02FWElql6WD0AgLaRKM075Riuk5C+jnu2S/tMGTL8L7xLdHvKOIwI9anEt66OtdXaxqhApOyytiH5Xewu2Et9cOTU55urb8l0LbQ7j66c7rb9/TYCft/zMj1/LFN24iaLUQTvgHFIunRqCmKhLkCL1dWLMFVvZDbi/osxONJTYg7627WQ75uvpB1Xrkz5R0JFr5Gyr0XjnBx06y97IFJ6bCMMStmLq228W9NJPW6AP0nbgO96HujGDd11uehXNCuOc+5LCx+dtIBVXKvmK7PW3nzRzyduwnqU1Hmk dJvqFb0b 3CHrEIYtJsN/5G5u6OoadHsY7t5KS49T1AfTFcB2IsSkO4kWFsmYQmwGpwJJgugsl/C6KHdUoM3nJrRmqpJbRY+dmLbpKUeDqa7u5uXV1eoAD2deQIcbggrYiu/Z752E9l8XHoOrl7Wx1/eqk/flNErKoVnLuWPygLfCeWM58Fms4bu8cBZjHC33eOkCiHtlO3+3owP5+Db/tRTmibNm3fNAzQ7tIe5Td/IjNdeD2wPgdhztuLpTahiV37omHyBdsb0TyDnrAuj3OoHLKKO3wQTBL9UZbYvTmmSOC0z8NqtHdevVrHRXdIzlpUjhqt0PrCOR/RxBQZr1X3UTdKYQL7NawmYLth2sz9tmW2lFd5nG9mcZ0kGXEZcdpCIXWcvmQBJ+V99f7DQ99S8Vuio+wgKGi09HYFbdR1GjILkUeDGoXe7aWJss9hoO/5K1E1umMAyhkKm6TP6Xuohfzv0LtLEC+5nT99iB0OwBiNMIcwrXw0iE4ARRpwn1RfHA7Y9GElAsD3lbg6EbTGgQ= 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: There are many places in the kernel where we need to zeroout larger chunks but the maximum segment we can zeroout at a time by ZERO_PAGE is limited by PAGE_SIZE. This concern was raised during the review of adding Large Block Size support to XFS[1][2]. This is especially annoying in block devices and filesystems where we attach multiple ZERO_PAGEs to the bio in different bvecs. With multipage bvec support in block layer, it is much more efficient to send out larger zero pages as a part of a single bvec. Some examples of places in the kernel where this could be useful: - blkdev_issue_zero_pages() - iomap_dio_zero() - vmalloc.c:zero_iter() - rxperf_process_call() - fscrypt_zeroout_range_inline_crypt() - bch2_checksum_update() ... We already have huge_zero_folio that is allocated on demand, and it will be deallocated by the shrinker if there are no users of it left. But to use huge_zero_folio, we need to pass a mm struct and the put_folio needs to be called in the destructor. This makes sense for systems that have memory constraints but for bigger servers, it does not matter if the PMD size is reasonable (like x86). Add a config option THP_HUGE_ZERO_PAGE_ALWAYS that will always allocate the huge_zero_folio, and it will never be freed. This makes using the huge_zero_folio without having to pass any mm struct and a call to put_folio in the destructor. I have converted blkdev_issue_zero_pages() as an example as a part of this series. I will send patches to individual subsystems using the huge_zero_folio once this gets upstreamed. Looking forward to some feedback. [1] https://lore.kernel.org/linux-xfs/20231027051847.GA7885@lst.de/ [2] https://lore.kernel.org/linux-xfs/ZitIK5OnR7ZNY0IG@infradead.org/ Changes since v1: - Added the config option based on the feedback from David. - Removed iomap patches so that I don't clutter this series with too many subsystems. Pankaj Raghav (2): mm: add THP_HUGE_ZERO_PAGE_ALWAYS config option block: use mm_huge_zero_folio in __blkdev_issue_zero_pages() arch/x86/Kconfig | 1 + block/blk-lib.c | 15 +++++++++--- mm/Kconfig | 12 +++++++++ mm/huge_memory.c | 63 ++++++++++++++++++++++++++++++++++++++---------- 4 files changed, 74 insertions(+), 17 deletions(-) base-commit: f1f6aceb82a55f87d04e2896ac3782162e7859bd -- 2.47.2