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 E4A76C3ABC9 for ; Fri, 16 May 2025 13:03:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6AF036B0163; Fri, 16 May 2025 09:03:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 660346B0164; Fri, 16 May 2025 09:03:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54E0C6B0165; Fri, 16 May 2025 09:03:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 35F2A6B0163 for ; Fri, 16 May 2025 09:03:47 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 38E891204AB for ; Fri, 16 May 2025 13:03:46 +0000 (UTC) X-FDA: 83448788052.11.39AFF3D Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by imf09.hostedemail.com (Postfix) with ESMTP id 3DC6A140022 for ; Fri, 16 May 2025 13:03:43 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=QhyCkFW3; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf09.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 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=1747400624; 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=k5jIIhYbIkxt9gsUjYrJMapDzXrc41ocEumqPERe5Cs=; b=p3fqfZDuKTntwpE/OZ2U5a7JDg1KqAWJRabOK2zLiTzDPyAcH+eRz33QJbBdKP1glyrdvj v6K72kzzFU1x/xVFo67MDjTswmIgcB0nFWRC46unU0Huulw/6yz9SKLbhxhUVhDMZ7yRzF O3zNC7yqKbEsbE00iRYe3I+CQNyNBP0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747400624; a=rsa-sha256; cv=none; b=EEb9L9vW3sSb6X7m3keR1m3dxvZM8cb92ZBanJW6oGr66T/M35BxxqEIh77SVcF/EGp8/M 36pmOV+prsHB6msT/Hwu03svvgLyWmHIe/hvaob1SOHd6tDNXkXWg9PZlE86p2txcSUbi9 8URDXCIlHrxhvBnQ+54JC0JOVz/ue/M= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=QhyCkFW3; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf09.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com 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-101.mailbox.org (Postfix) with ESMTPS id 4ZzS2237KPz9svH; Fri, 16 May 2025 15:03:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1747400618; 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: in-reply-to:in-reply-to:references:references; bh=k5jIIhYbIkxt9gsUjYrJMapDzXrc41ocEumqPERe5Cs=; b=QhyCkFW31XORoLY8RESpZbYqT50XjDBcU+SVfRlQPDM0GXbC1rqrz42fO+APu6Vt7KFGpk 52oevjikdjxD5HPX2wsR/CLt+/Rr+lLllu800VS9lTCYKKaTwJpQUdwnK6X9VAqKycemSe 1Bdd7XrEqt2UdBXwWiIVDM2kUpq/Zdt5SP9KN0nEY1wd9d/p0KKyKyiQZpOGj6/e7VwRQA /AMn3ZclX85uUcBA8+2MKbpzutKJDhQObyF8pnZp4Ol6DSLpzxwtLShv9WmJ5OzUEL04jN ehK9qq9MlhDifqNjW2mmaibRQXHSTBy2aGPcNZrtHXW7pwumV0T7bxHfljhm6Q== Date: Fri, 16 May 2025 15:03:30 +0200 From: "Pankaj Raghav (Samsung)" To: David Hildenbrand Cc: Pankaj Raghav , "Darrick J . Wong" , hch@lst.de, willy@infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, mcgrof@kernel.org, gost.dev@samsung.com, Andrew Morton Subject: Re: [RFC 1/3] mm: add large zero page for efficient zeroing of larger segments Message-ID: References: <20250516101054.676046-1-p.raghav@samsung.com> <20250516101054.676046-2-p.raghav@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: z7rdmk4gia76u76p8fwebq1fcpxuhx93 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3DC6A140022 X-HE-Tag: 1747400623-976725 X-HE-Meta: U2FsdGVkX1+xOoSPz0pmGEkYP2VOlFY3OCYYMnH9xlsNwIof7vis/2uqC16dFin98bK0dVjkqphZFAGRS1Lp6aPACJqb0Qg3FV9ek9zAwCT2p9YiWWfQahQGCEr1hL/gHymTyZ1p9xXijbJZyumpf5ltavcy0y8UbW114fDg5ecPT1WBh39SU+zWm1uh3TzVolOdXLuC09bzXcQDs5IGRqcL8uPDz+JFUr1Xyq1PE+TsoEciu1+pNZcLekzj86kcLYMcWBFvC6Q4Mdxd3ubTKaOIrNeCB+lHMNh1pJLYfK87uOU/vXpHwUMdue7P7kAad4gs9k5gwwRRj+402VNiZp2Xu2JeStFM0VdICl19qlmLAT9tunRflUW4Pude0L9QrU7SyWqd/YjeF/I31PKBcReJjvqxykq3mrTPsxmNoeYWtWSn46PADnuMTRTqc7DGDwVut8vopsJgZGHvftJUlSvfuoIoDmsny78mk2sYpDP77R0klQQwi84zJjoIF77cvGXTgf/f0lxGsMo7eeDZ+fLAuRFTilEeEr4fWFVKX6OE9KWO9sVktRrvBqtapgdEEGUWvMpvwJXJMrX8SRshOTh+Uhqpfi2q0YoX3VFIETj572yifh9VLwW/1wGDMZLTs1lkzeub6z/Qb3jl6bP89KCKD3BnkcRuhiqrz6cWgJVxQ29eUyHKa8UFZilLOoZpRx2tZrcl49YgkXrdoQk3CMSjxklc7Zg97jvX9u91MMzpt4xZoyi5GKiaMqPmxkDWs3NMD+4PWdfUp/QiEOkfob4rftaLhBFjEAPR4aOgt2EN7kMW70Y7U8wO+bDfZ2//gc0DhvdWNjO23w13fESJEypcAKMKVPStYBr6l4qDYIrkf2IR9AbR+oH3RT+5f2hMQ9Pq7w6H4Z2aEM0G6c8ml5jSG0TPsOYQzUqsrvYIdnQBMRacXvrRKtIGh62tm8p0b4FYYBeys81rO6+24nf L5KUhkYo wj4YBkdpKMKGOMWTJuAJS8OLq0ddvw9/0XqD2oWIHbvCGH9yAa9OIzxKGHFGGKVKBR5+ydCxNRTBqPfkFl9DkFDnWjJFysQ7iwTIU8IaKeVxg/FeWsMSlczp3iOSkivN0/8ngr74HcKnch6D/Fk2tBxEYzrpsCSdGsoNO5pcsodv7Fr0fzwJ4mfD5Eaq65ePsWWbCjqzwK9wU6AGRs8zRw9k9XYaEWCM8zVZV396MTIMkztRavU6yJJ/6iciYwkR9R6IjUnuEZ2lw3f0= 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 Fri, May 16, 2025 at 02:21:04PM +0200, David Hildenbrand wrote: > On 16.05.25 12:10, Pankaj Raghav wrote: > > Introduce LARGE_ZERO_PAGE of size 2M as an alternative to ZERO_PAGE of > > size PAGE_SIZE. > > > > There are many places in the kernel where we need to zeroout larger > > chunks but the maximum segment we can zeroout at a time 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. > > > > While there are other options such as huge_zero_page, they can fail > > based on the system memory pressure requiring a fallback to ZERO_PAGE[3]. > > Instead of adding another one, why not have a config option that will always > allocate the huge zeropage, and never free it? > > I mean, the whole thing about dynamically allocating/freeing it was for > memory-constrained systems. For large systems, we just don't care. That sounds like a good idea. I was just worried about wasting too much memory with a huge page in systems with 64k page size. But it can always be disabled by putting it behind a config. Thanks, David. I will wait to see what others think but what you suggested sounds like a good idea on how to proceed. -- Pankaj Raghav