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 8427EC83F17 for ; Tue, 15 Jul 2025 14:15:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26DF76B00A8; Tue, 15 Jul 2025 10:15:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21F0A6B00A9; Tue, 15 Jul 2025 10:15:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10E176B00AA; Tue, 15 Jul 2025 10:15:24 -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 F0AB46B00A8 for ; Tue, 15 Jul 2025 10:15:23 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9AC6710FBDC for ; Tue, 15 Jul 2025 14:15:23 +0000 (UTC) X-FDA: 83666696526.15.8781C2B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 342B5100015 for ; Tue, 15 Jul 2025 14:15:21 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="RS/h8ILT"; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752588921; 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=uHaC3NM9+QwIy3pXqxbGtfDGOu55CkwVkRhyKfVul1g=; b=5daS+MEweK2s6vJq80WTpDz+nt42WlU/EZAuUolHrOTYVHMzVQ39opcDs6MYVHIj8b1hQ2 tkRCrkWYyF1RA+4xDFh6ml+ant/AV2Zel7fJZNI5n9zqWH6dvpb7fhacWHA5XDSwuEEEaC 3mawiZrbTdOadr0xfxWwWAgx+4/ud8k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752588921; a=rsa-sha256; cv=none; b=CH7Po9d44AyE8wEJIIFG67JRzA2omXjSWoJPEzbKd2WXF9XKQ569z1Xsw8VNNkYG5ulYha Hd+wOTRXlT29JLuuvWbFR8LoLqpWNmpwBy9isOkVeRNB7L6jahRTMzWwK1cy4CVHOnnVFp wsDNT6jJ5DhI4G78vJ7Jp0u7IEGnABY= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="RS/h8ILT"; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752588920; h=from:from: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; bh=uHaC3NM9+QwIy3pXqxbGtfDGOu55CkwVkRhyKfVul1g=; b=RS/h8ILTxCb8n5PbO/zm4CqfWFNjIWAGdrHRQmru+rf+v9AiBVIgPEGdU0S85OBTp3wUpf qcFBnWvOmC3scuQ3oIPVgJ4M/hd/2A61rRx0fUfR0dwtQA6Yk64mWXscwsDxWOHK1E74HJ RadtV8HlNrxnaKJT8mcTvlcAvapm9g8= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-620-OPCXMrBLMMG0FzhGcmDbAA-1; Tue, 15 Jul 2025 10:15:13 -0400 X-MC-Unique: OPCXMrBLMMG0FzhGcmDbAA-1 X-Mimecast-MFC-AGG-ID: OPCXMrBLMMG0FzhGcmDbAA_1752588912 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3a4f65a705dso3655632f8f.2 for ; Tue, 15 Jul 2025 07:15:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752588912; x=1753193712; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uHaC3NM9+QwIy3pXqxbGtfDGOu55CkwVkRhyKfVul1g=; b=bTHoZvJVLkX3T0sskcHn9EuQqNqn4pqwSrcrgicPqM92QMRKywDQaXm3m7KAVWfjSZ Lmf2pwpwp2N1hRk+Nud8q1mowbtOk/fkOtrlq6RVhxGaLur2Ejf49GOMpvx4ElFURMo1 Maf9q3jVft5CJahlKqdiZLl21y8IaxvOYpvHQnbf6UkHhDUyFEWQKJH9gLRjqDI09fYa wwPvq5lwkmRaKA88QLzLS6nEDwmhtONbkW9AvwDs9Zf8KpHHWd76ai4HhiCr4fhcfZ+N x+ciJDRS4UEioXahQJ+0gXxHnUa9Hwh4QUmoryn+cQXRzSkJFjI9pS0ceJeXdizj0wyp d6Eg== X-Forwarded-Encrypted: i=1; AJvYcCVpoUr1IQkE3d/E1SD5au12ffRLGx5Ri5suIvJYF04KMIETo97uKBPqKTZqvaJgrH+01mT0+/aUTg==@kvack.org X-Gm-Message-State: AOJu0YzCWGbqQAr0r0VHs6a+VccAKmZMlfDD/BNFrBZpWkwxIPRSgN7V bi84w1BQDG79DqeBgtb4B5XIemd0BM96CLBFEFr+7/Erga5gMArhArDCI+aKpQPmVmGDTbWfJRj Lo/ErHHGW6DycrP+CUst4nT+m7QcCaQQlVLhsBdSUJQapc7wGTCUx X-Gm-Gg: ASbGnctSS+iP0RyfLduIcy2mPzmEmHJddtf1TYY8mn1xqzrpPTCNUIZckdzepPK5ULr eD3XRFKLYw2psJFjTwo5d/A9/nTeJWobbIMg199h4CzoWPGYmz/5Dc6nh5OfUGULJyXX6NYkeNb eP1VtQPhK8DD75Tr76jiA0ysjaehYfSZ8iRycnF1NhP24SCP6vXqtd/QM7eD6ozVl8/LIjz1y+n 3Eyjlm3ZzHhRLD05JS3b+9zLjwzSc7RRSy8HQG5KSknVu/qy2sfMPYftnwAAl7tzZ1Ydvvic+oP yk20/ayoqzdx/GXcLTWX4twvBG2ob9FNw13AFI2wbynoiFY65QQ0bXoGbGZn9sBYpa3JWTY7Xcv ugvSBc4Xv/PD00pAxmNl+084AQHRFCAwBBvvW9ZBCRW+zDK3lkb5lU3HzQh250PO3DW0= X-Received: by 2002:a5d:5d0c:0:b0:3a4:e629:6504 with SMTP id ffacd0b85a97d-3b5f2e448d9mr10913837f8f.49.1752588912211; Tue, 15 Jul 2025 07:15:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFpyohQnpn/KxIdJ2KMc18WnTagGh3ivybzKaAC/ozw+/YD8D8CtWgwEjyEVReYxDXso7vSlw== X-Received: by 2002:a5d:5d0c:0:b0:3a4:e629:6504 with SMTP id ffacd0b85a97d-3b5f2e448d9mr10913779f8f.49.1752588911647; Tue, 15 Jul 2025 07:15:11 -0700 (PDT) Received: from ?IPV6:2003:d8:2f28:4900:2c24:4e20:1f21:9fbd? (p200300d82f2849002c244e201f219fbd.dip0.t-ipconnect.de. [2003:d8:2f28:4900:2c24:4e20:1f21:9fbd]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b5e8bd1833sm14841701f8f.8.2025.07.15.07.15.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 07:15:11 -0700 (PDT) Message-ID: <9c9b78fd-4698-4982-919c-34e679bbac84@redhat.com> Date: Tue, 15 Jul 2025 16:15:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 0/5] add static PMD zero page support To: Andrew Morton , "Pankaj Raghav (Samsung)" Cc: Suren Baghdasaryan , Ryan Roberts , Baolin Wang , Borislav Petkov , Ingo Molnar , "H . Peter Anvin" , Vlastimil Babka , Zi Yan , Mike Rapoport , Dave Hansen , Michal Hocko , Lorenzo Stoakes , Thomas Gleixner , Nico Pache , Dev Jain , "Liam R . Howlett" , Jens Axboe , linux-kernel@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org, x86@kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" , mcgrof@kernel.org, gost.dev@samsung.com, hch@lst.de, Pankaj Raghav References: <20250707142319.319642-1-kernel@pankajraghav.com> <20250707153844.d868f7cfe16830cce66f3929@linux-foundation.org> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20250707153844.d868f7cfe16830cce66f3929@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: yjQvDoT1kKSgzncbIXcCsV7ZXPPg8CidllJqSTYvydI_1752588912 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 342B5100015 X-Stat-Signature: yh7ud4r6psgxaa4nmjj91nkdgteyxc4n X-Rspam-User: X-HE-Tag: 1752588921-936491 X-HE-Meta: U2FsdGVkX18vvo4RXOmxiT089z31N2ZXzH1N/icyEVYmpeGnj86tloDNB9bxlSJLId98oYN697Tunk9As41wYhW6FsM5LKYG1BRiOd9qiBL+A35F9ZAAnBMbswWIf2MnpItEUCkxve5KHaGdyfdm5CKTGCU+KipkHKxELDu/y2BhU6eMBzR6/Wuy5oMXa3xknRHopUO1GX2W0uFrdK8epXAcd09vT79ekL6FWZH2NvHhnjxmgriFyWOWMVaOC4iLvgqHuHOluEvsRetQYNR88sujUWPxfpuXazTIa3PGtiw0Mhnz7gockTheH2jGesMXeoYWtfRLYX7OvOuow+JSN2mEJB4o11ZzW/OwnJ2iq9sRv2x55mWgBnHGeCy4J7qr5fBnV2j9c3WtFaWRTA380s+kuKAncANlW5xUzAAtKZ8P7hl4GniNA5zJqU3y9mFfrlEMBrf5gQ9waSy1hiBj4/JciM4uz/wO5zH6TPsKyTLuVxnPAlvjEOO/yU+nerrEHpy6CP8k0EWW3SNKmxzSK+DOufnB0Gn+mG+GpJABPZmJbWfEwrSEh/MYb/NcdRv4W4BC1KonnwCd3lf1Ob0IZZsE+vfIN6YfB5jHaGXNbi0Z7PW/mCxYEt5Kt4zhiUQbk1CRBP/Yfjvy18ceYxaJxY4/hCH2ObpzBWelzXpGfLCBRgR5d5fkbz0d6XuYzK4TFUOqKR4ZxeG9+hCkDkCTFRt6JI/EuKOLRhaVwcvT6Sfoh+XC55uiyuWp/YJasXhFqkR0zkh1/7p+TshG9tKWxURhvO2C2QkD0GBoJEnRFDpbqJh5mM5YMUIExXL0wRDPhPlTtxSQ1T7aR5u02dZNhfpmQNpSKY6mhLxJbQZNlMmfERUOH7s2U8Pn4N/BDkQ+MlRICfNKbXRJPgINstZLx8qFztkrc1P0G+X1IuVpzTYj64L2ockAHq//tLy+b1/WvKfsz+pKGT8hZX9B01e oqNpM3uk I32m6u4UF74RQfVv2LP+EyBwUqjI0lZZALlvYyXLEBX9XBBjONhuL4WQqd7WLrAEHCG4XdTLF4KMFRNRvFUm4lJa2znoca9snkd+W2khhJ6P3iiyP49bHynn1aHRSMaKydhpWXvpRpyBTpciaZNwSwblz1hor3aUVCpD415kB4ttVnv8juMmoQ+XbMIIdEfmb1YRmD/BEXl2uPpfWaDzeSgKy3ZJexh9Iis4xtkmxAz9vGtGDPUQZc2thaIazVgYdwXziXzZmD1ysq+MxDjubVPopJl44OkOCPqxV7G3Xx0aFKxdcqDxCOFrnV5LZ0m+Pqdg5zlp4dfOIYK7bfAgF4hwqLbkROpKvUhqDjMjnLB6wHUs326DYNPTO+y7uXeTIucCqJThBx1k3jrG+lMOC4mMiyY0EGEiWE3Klw3O97Sn3B3f16UfKrfwxarAOTCC0CJ7NiN4OeRgGJ5Lp6y/4rduqbEnSBCRu2L82LHZV+Di1rCb9n9cjltSymU30va39FYmWCMNsCUT77aA= 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: On 08.07.25 00:38, Andrew Morton wrote: > On Mon, 7 Jul 2025 16:23:14 +0200 "Pankaj Raghav (Samsung)" wrote: > >> 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. >> >> At moment, huge_zero_folio infrastructure refcount is tied to the process >> lifetime that created it. This might not work for bio layer as the completions >> can be async and the process that created the huge_zero_folio might no >> longer be alive. > > Can we change that? Alter the refcounting model so that dropping the > final reference at interrupt time works as expected? I would hope that we can drop that whole shrinking+freeing mechanism at some point, and simply always keep it around once allocated. Any unprivileged process can keep the huge zero folio mapped and, therefore, around, until that process is killed ... But I assume some people might still have an opinion on the shrinker, so for the time being having a second static model might be less controversial. (I don't think we should be refcounting the huge zerofolio in the long term) -- Cheers, David / dhildenb