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 28ACEC83F17 for ; Tue, 15 Jul 2025 14:22:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA2A28D0003; Tue, 15 Jul 2025 10:22:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B53268D0001; Tue, 15 Jul 2025 10:22:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A41CA8D0003; Tue, 15 Jul 2025 10:22:05 -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 906598D0001 for ; Tue, 15 Jul 2025 10:22:05 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 35C901DA469 for ; Tue, 15 Jul 2025 14:22:05 +0000 (UTC) X-FDA: 83666713410.07.0F89F4B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf13.hostedemail.com (Postfix) with ESMTP id D4BB02000B for ; Tue, 15 Jul 2025 14:22:02 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I+2wgWrl; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752589323; a=rsa-sha256; cv=none; b=HSU/RH7gSVdRgp48EXV+RdUbb0m+9Ig1EgY24xZE8rjpUYwbMgBX6PCyK/X0ZYgfTwh5/b AcYAnP4Xe8r8zMHV4jXGMsecQqjP+YRRdwA+yUMFa63J8d20aaTuzn7aF8DSYrEnuFsdGb BtA5EHhuNBoF3+Xikcc+s7EfCSL38eQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=I+2wgWrl; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf13.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752589323; 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=oDrEGUfdEY5bNUZj0OPBlZFo/nFLzvL2Qn0I2Pn5t0w=; b=YX/TyIkedocvQyEPDMM9Ze88MHrPopaSXXWvdGAh77ymm40yK2N6NSLvABFbcsDiHJZ5in U6CHoVZx2Kn++1+OKj0DDHt8LFya3figwNTzGQ/mPy2CmzFVChWYO7iqt0oPfiFPoFP+Sp 82dwTFgP9XFxi1dIU1mH5KHFRMEd42U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752589322; 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=oDrEGUfdEY5bNUZj0OPBlZFo/nFLzvL2Qn0I2Pn5t0w=; b=I+2wgWrluEe7HTGbGvCg1KJ0YLtRiE1/D11mGVwM4jF5WIg4PgmRTbaKyuqEtl1BOuoQTu UEaz+vTG9y0KpoaojIYCwVZNxqn6SW7nkvi0DJwr/cFmOIaNbuCa83XM0aCWFWrDZOiHOw yBbQEWg3xltltyDJurgCUFPj0vDAmWA= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-338-YUxXo65hObmKLrBe_SZ3tg-1; Tue, 15 Jul 2025 10:22:01 -0400 X-MC-Unique: YUxXo65hObmKLrBe_SZ3tg-1 X-Mimecast-MFC-AGG-ID: YUxXo65hObmKLrBe_SZ3tg_1752589320 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-455ea9cb0beso32847525e9.0 for ; Tue, 15 Jul 2025 07:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752589320; x=1753194120; 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=oDrEGUfdEY5bNUZj0OPBlZFo/nFLzvL2Qn0I2Pn5t0w=; b=hS1LXWp3450FlP81WmGjb8/leA6auRmb9HqHbRr4Q7peUDmkt4UZTdhZDRxX9igmbg v+9qXM7ROZVGqkVmuQQqHb9qk4yh/Rm4ZOdSTElMzqPmDqiZXbORjw4pJ8BbW284jv+B IIPM4hTQDdR7fQu8FoodoepCqE/uGEYnssP0NYGQrYhMFkOnF4/fR58XfEkRlgO8TJcY mn4o5TpXXe3pHmWVbaozgTzLBfrjRKIYaHZchXbiodU5sv36NYj16KGPw8SUjYruQieM FPEDaUC3tS6zHrVreFdyjGT0rYIAy7jAu5pTYtEHFl+QPM+VERR//KofiGx4DXyEbuQm IQ4A== X-Forwarded-Encrypted: i=1; AJvYcCWGM9bP8or9qKUpF+IkGDEoQUvds1so9/+6H+8fwcMs8Is//LUIByGJBGgbroc2gKmWcRQq0hdGYA==@kvack.org X-Gm-Message-State: AOJu0YzOa+URekbIE4leutARb5yENkM6YclxSFMcFVY8tzIr+/R9Yq4s nEKjpBA8F0jI15VGrcoS8nmGH3UdFFLzp9RO99OEoszwx9AVNjK5jXA2kueR+tr7n5n2HFYhm2Y /mEUJdQ4UGMM6ybsKW7+zfmga1ajW54irQqDOFDNxuDMApx8KeGnt X-Gm-Gg: ASbGncvBt6b0Vgp8LpjAQOnU+p8BzCihp7IggZuOoJOGrsAsoYidfKRLkTXa+m5Yn4x LFsYUzvYYgm+O9KnQSkbTn8WAxrHNZOGUyZeOvhcGuONUaNJr3DHLcE6fsilzVxOmy9knvkHglt 7wUzI0Dtv+HoAwTOwCw7YV/267onA7L80kSOC3TJ3p6VS7kuVVXPZUobchyqgfqjQgnKjvP8lR5 NaEEzpnBq+8eYIVGbB2pBZk/ttmuo63u4DWRJLSFXNMpd3YltE0M58TMR8Zwg6oHYF3pvoqSDc0 z03AA85OySt8p8cX+buXyTFN7qmtQjJ0iOV0R0PA87mk6DXG8a5f3au52EJk04x4xmNr7uDyvj1 DLhJbVZ48sUvoWcpx8Byi/HxzEfWVDLaKrLH+iLdlokT2I9KsxmLtzYk3Gif0Az4S/9g= X-Received: by 2002:a05:600c:a208:b0:456:27a4:50ac with SMTP id 5b1f17b1804b1-45627a4535fmr16117255e9.23.1752589319844; Tue, 15 Jul 2025 07:21:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFmFicQGLhaeIqIZaRygdy0pZOKRG2JvGq7gYgR7tSdKq9ZAb0t0UWibnFtXm6Rsiqbr86/Tg== X-Received: by 2002:a05:600c:a208:b0:456:27a4:50ac with SMTP id 5b1f17b1804b1-45627a4535fmr16117065e9.23.1752589319405; Tue, 15 Jul 2025 07:21:59 -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-3b5e8e1e135sm15388978f8f.72.2025.07.15.07.21.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 07:21:58 -0700 (PDT) Message-ID: <26fded53-b79d-4538-bc56-3d2055eb5d62@redhat.com> Date: Tue, 15 Jul 2025 16:21:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/5] mm: add static PMD zero page To: "Pankaj Raghav (Samsung)" , 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 , Andrew Morton , Thomas Gleixner , Nico Pache , Dev Jain , "Liam R . Howlett" , Jens Axboe Cc: 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> <20250707142319.319642-4-kernel@pankajraghav.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20250707142319.319642-4-kernel@pankajraghav.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: gq_3AHE16-jRzkVU0Ft2U5cVPYpVmFIIYM9qi2r5nw8_1752589320 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: D4BB02000B X-Stat-Signature: fsqgo95zcc3kk6m5868ejmiqcsjss3nb X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1752589322-599675 X-HE-Meta: U2FsdGVkX19+RcMAoG6IdTo646C8KHQbA8yrSlzqy6KcpAkcGJQ9O8fkZqYCS6zOLJmXCU7nTVPxZ6Qoj/m1JU1o8gBUnXlvjswt2644yM+o/qIpEzoI6PbqrYnAhMqAUPmtXdGevcFx121XQGNSDxqB3yWQnYx1iZr1AWPWxywr9WTDx4xFDmJYbFMbdhrYuoMYc9f8rgqVDjaZNN1dTWCfCu6DG1Y026K+wF22I6+ZepxtSM/UTiyiUTxS50KVHjFNBiSZO89hjoPHk/994i786yCjoXjytIa4gf9AOntAxUIbLe4h8dgt1cxOImQVJUks6HoOuu1KTzacr29VqptUxugQauT6ki2+69+drPQGrYZkmXhcYmS8Z02uowt2YyIYSRCdmdcRWdX6Vbsn1CsnoWZ9cguUGEy52oM+OIUFmGU1yVK1V70Q+pSL9Uameu05TLdK5wPgybJc+1w5+io0F8r1UGxKYGhAPdttkaSn3P17eTIjaJrH0uFKEipsfPJT4fLCL/ggzOO5lSoeKOlMwEuPPUM1ERsBX5eNNc7Wdolk92nPl5JTC/xNFHqHxN+CjoJ/LnstJXEgOpdiwPU+Iu/XsRSPrQnOibE5on5MlhilihnrnUtdsHavkb8bzZUWBgT0G6ZrNp+qFk9g0XjhXaiJsJDjdVAPMRlXcslt/oe1ATF1egZSN9MY3+X6JlhR0sSGIEsoVfE1ckjF/umIjJ+2o9FaMcNRvysDYna9I5OosZUwJWfB3vv1qk+9nc2UgPKBYvoLYOSL7lL3qzqUlhfb1zWLluSfdZp3BSmGF4XCwG4k3C9k0wdOBYSJdLq9U0CoMI7DNZehlM10SGJT+dc90razOU/7NABh+ldmdndnRzA0h8RBgstA2m5vKtCViVCbOhYY9j7deZX+Pa8P7TdnWa3bDoZq8GIgmw3ArJAXR3jEEjNNRh8uy7Us3kmn+x+eF0Ul04cv1Xg INrYjK74 RB3KfQgKG/93Uqz3q/wfqcetKAmz6MFqHvvpbZQXdyl5s9VQwTY/fH5fOWnJwuwEhIQB4QE70jfgX41mUrRxX6iK6kjTDKSqFan+0xeqanKt2dRBRwtyCH8/Qd2j/UI8XVv6Je4BEpB/AT/546oyaZIXD/yNadZB0w99FF0e37g36M588Dy7pEiZE7AeK8HvPWkQfBIeCqQUtMjt3+K6EQ/z+T79XlsQDssY49rXIrlKTn3S35gFnrd9sUMfxA+/GPwJpM+7k5k0viY5n8dtwkagee6i+/QAMSKDW/CXr5Oto90QFJBZ0liq/cqHZXj5Yjl/Eks/U3fETJVoktPK0b/KtqkRyIFf8bL8Wbb3SN4UiYY/B75G1YDU96friT8C2V/Q0xJrtA5lyALX4oXVytlBSRXwyhj4lLgCZfOHM/0G98BQkJT1Qp19vVukhNAwQRFGnwTAMiv2N6OCCC+J94ISrGfp9MFjSHSb7PsOI6dWSI3E= 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 07.07.25 16:23, Pankaj Raghav (Samsung) wrote: > From: Pankaj Raghav > > 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 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 single bvec. > > This concern was raised during the review of adding LBS support to > XFS[1][2]. > > Usually huge_zero_folio 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 completitions > can be async and the process that created the huge_zero_folio might no > longer be alive. Of course, what we could do is indicating that there is any untracked reference to the huge zero folio, and then simply refuse to free it for all eternity. Essentially, every any non-mm reference -> un-shrinkable. We'd still be allocating the huge zero folio dynamically. We could try allocating it on first usage either from memblock, or from the buddy if already around. Then, we'd only need a config option to allow for that to happen. -- Cheers, David / dhildenb