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 B749BC54ED1 for ; Tue, 27 May 2025 18:01:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F6AE6B007B; Tue, 27 May 2025 14:01:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A6D96B0082; Tue, 27 May 2025 14:01:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BEE76B0083; Tue, 27 May 2025 14:01:18 -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 E390A6B007B for ; Tue, 27 May 2025 14:01:17 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 952BFBEE10 for ; Tue, 27 May 2025 18:01:17 +0000 (UTC) X-FDA: 83489454594.16.3B96E3E Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by imf26.hostedemail.com (Postfix) with ESMTP id 471AB14001C for ; Tue, 27 May 2025 18:01:15 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=JAx2E2LP; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf26.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748368876; a=rsa-sha256; cv=none; b=NUWnvRIzED1QRGH+wghjNHLC7nU5DwxEozm/CCLIT6L0PHJjCEBTNq/pqJ71PseN++7+za Pyq4V/Jd2o1gANnJLF+cRDzIn8T59H8old/LK7qkGlMzaU4tbYKkfNlgcFJ7WHoAQ0OJ3r Az9g4tsvQL/G2+PeoU17wk9M+H1fS7A= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=JAx2E2LP; dmarc=pass (policy=quarantine) header.from=pankajraghav.com; spf=pass (imf26.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=1748368876; 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=WDYlu01ERbR/ASESDCpdVLMfWx7Sul+gusj5BFguHbc=; b=scPLnnOMGV2m7hKvtJ4HrXLzxGe6DtoHOgwWpTGUTAvDH4nkqNgsWg0xMZ09FZkhQhzykF 7s7dGRuL6zPuySCHhLrm89YmeT07lRgqgGe8G8KDeZUDQuKGv0oRexdneDsiqDWEXwvSyW ruNxuSAbrvUucchA7lTdBCAMXU1wruU= Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.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 4b6L6G48htz9sRk; Tue, 27 May 2025 20:01:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1748368870; 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=WDYlu01ERbR/ASESDCpdVLMfWx7Sul+gusj5BFguHbc=; b=JAx2E2LPxX/GiBDVDJWYxbga4OGfdUGa6ljxiOeDxJIaivADn5M8vIIkuB4R6ksdfzLQdy thbZ9KqY9mRXC2nxJPzkD2p6tcE3lLz/plUI0av79uByUYqWdwU3yuDhCPnZ2zie1HrCFP 1qwFWtj0HaEzJ3T800KRKKPmTewtI17BfxkFi2fMq4TsfFjsBV/anLEKYpLAlTCCkEM3Jq Ek3UoE7/zHNN4RnOUwGsRUiIcvpUSvVQtXcWw5i7HkcwbcAMMLNCnkjGj9bt9PGEalbbKU jBCbnODDEpfDdHlYSPaKmeRz1Wyceextp9oSaAODxjdccPtcBgFUCkoJz89+xw== Date: Tue, 27 May 2025 20:00:50 +0200 From: "Pankaj Raghav (Samsung)" To: Dave Hansen Cc: Pankaj Raghav , Suren Baghdasaryan , Ryan Roberts , Vlastimil Babka , Baolin Wang , Borislav Petkov , Ingo Molnar , "H . Peter Anvin" , Zi Yan , Mike Rapoport , Dave Hansen , Michal Hocko , David Hildenbrand , Lorenzo Stoakes , Andrew Morton , Thomas Gleixner , Nico Pache , Dev Jain , "Liam R . Howlett" , Jens Axboe , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, willy@infradead.org, x86@kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" , mcgrof@kernel.org, gost.dev@samsung.com, hch@lst.de Subject: Re: [RFC 2/3] mm: add STATIC_PMD_ZERO_PAGE config option Message-ID: <5dv5hsfvbdwyjlkxaeo2g43v6n4xe6ut7pjf6igrv7b25y2m5a@blllpcht5euu> References: <20250527050452.817674-1-p.raghav@samsung.com> <20250527050452.817674-3-p.raghav@samsung.com> <626be90e-fa54-4ae9-8cad-d3b7eb3e59f7@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <626be90e-fa54-4ae9-8cad-d3b7eb3e59f7@intel.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 471AB14001C X-Stat-Signature: xuxm7hxqfxouy5575kjkcpe8gu3o4wg9 X-Rspam-User: X-HE-Tag: 1748368875-628790 X-HE-Meta: U2FsdGVkX18zdprOAPD6R9/tMm7WTZaKwLyKPLoakHwu56XOAweAMWqjSIUMRr3l+ed9F3S13UB+SlzTVfgAyf+3ebjbr5ozn7/fc+gbTiJzvUx1hoY8O/6DtVYLEfBP35geDrxZVsaftRuiMNIjhDSh6XDknjFK88HMVzGTp2PyfPKE9mcKJA+6WPVUTnIVQRM0z9/fjWCXH2W1PiaJz6prfiN2Oyn2sYXFgeLdJg0bJk4AjpXe0KsDy9TAYn42eH4Nwu9/hwNa3co9CNq9K4CgBvvNTmDQlNnv55iaJo8emYkciRHaQUFlFbNmj62FwGiQTM0ElreifooQLwhOt1kjsR1X8AbmXsPlpSh76kS4yApniSJ7lsW8JTXL5mL4KIHugEYMQW0lXcocvRBdxNLFOV0xuY8uX4WMs+02eYhr4Jbk0+1NuIShBOu5u6vXw9eNjmkqQj/3Nu7mf+dZgkvTyEq/ys05rsIYB3VqZ5Lc3unjqeGr/TYCWgFdpWDm6SBMg7emYVytAxtAmiDhaCFMo3h4PIpyJM2V+0YD12aFYxjpHGL1BaJkViUF5reGyvFsNYQGO25LMVjTOAETTQLDPSsEI1ONWCCCxRYv18MZ+JC1G+f6aTS3H1Vfw4h4oaN2PDOOCJbo2F3Y4DgLDzv9f21EyO8Ha/cDlx5RvcDh6u8URRjQ9wsTO6g1bDHIL0gulh6xxTdoZbulZLM0oHFe96zqn4s+umJ/xN5hXCEQatEzEZVLlkI+cEob4RDBcEUMYT804cMTUwN2I4fdT/M+hCovysZV6skDb4WBVSPcrCq3/qmumHExaNqBPGcjU89QcPZ2ANHGVcnA3Smaq7ATusHVUfCCtIPsLZ1jjv7YnsQ53PLlrDqVkShlX2A4c8S+2s17eeX9pfteiOzoPKU2+khv/5FpdwY2KNjx6cJWtEMQD/8t8IT7NhbuX22eyuMYFB++s7XhEt2arUc Z7YzRxSW r5U3OocPCXJKyKT8CSXKPcE6PFSKt2Kr5qleXJmn6HSM56OiXsse6D9OWSiAjz2fYrS0r+Qs2FBWOzxlzIOyQAKQoKp6SqnvZFt1APtoTmPfjtP2GloT8qNtGD+MflxwNpIBl3iX7F41k3ASxAreuhi9Exg8fds0DzPk7f+Ey0ydCviTQv3+5Rdbg2GEXvym3w52Np2y3V8UAW9LfNi+fqNCfK1gF8e+9zwkMFNQLuB4vRXBtk9OXXM+hSxMth5w/VOAc9MN1fw2gs8V/6+b35wv/b0hUleD45Tp++uAtbweVSL2xDWTGnUny5F7bEExLnM5/DBdG+4uZKRnEr8LasUpiZ20rZalKPAlkY3h1f4YR4g69PIO03Wsfp5XehlACeZZV 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 Tue, May 27, 2025 at 09:37:50AM -0700, Dave Hansen wrote: > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > index 055204dc211d..96f99b4f96ea 100644 > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -152,6 +152,7 @@ config X86 > > select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP if X86_64 > > select ARCH_WANT_HUGETLB_VMEMMAP_PREINIT if X86_64 > > select ARCH_WANTS_THP_SWAP if X86_64 > > + select ARCH_WANTS_STATIC_PMD_ZERO_PAGE if X86_64 > > I don't think this should be the default. There are lots of little > x86_64 VMs sitting around and 2MB might be significant to them. This is the feedback I wanted. I will make it optional. > > +config ARCH_WANTS_STATIC_PMD_ZERO_PAGE > > + bool > > + > > +config STATIC_PMD_ZERO_PAGE > > + def_bool y > > + depends on ARCH_WANTS_STATIC_PMD_ZERO_PAGE > > + help > > + Typically huge_zero_folio, which is a PMD page of zeroes, is allocated > > + on demand and deallocated when not in use. This option will always > > + allocate huge_zero_folio for zeroing and it is never deallocated. > > + Not suitable for memory constrained systems. > > "Static" seems like a weird term to use for this. I was really expecting > to see a 2MB object that gets allocated in .bss or something rather than > a dynamically allocated page that's just never freed. My first proposal was along those lines[0] (sorry I messed up version while sending the patches). David Hilderbrand suggested to leverage the infrastructure we already have in huge_memory. > > > menuconfig TRANSPARENT_HUGEPAGE > > bool "Transparent Hugepage Support" > > depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE && !PREEMPT_RT > > diff --git a/mm/memory.c b/mm/memory.c > > index 11edc4d66e74..ab8c16d04307 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -203,9 +203,17 @@ static void put_huge_zero_page(void) > > BUG_ON(atomic_dec_and_test(&huge_zero_refcount)); > > } > > > > +/* > > + * If STATIC_PMD_ZERO_PAGE is enabled, @mm can be NULL, i.e, the huge_zero_folio > > + * is not associated with any mm_struct. > > +*/ > > I get that callers have to handle failure. But isn't this pretty nasty > for mm==NULL callers to be *guaranteed* to fail? They'll generate code > for the success case that will never even run. > The idea was to still have dynamic allocation possible even if this config was disabled. You are right that if this config is disabled, the callers with NULL mm struct are guaranteed to fail, but we are not generating extra code because there are still users who want dynamic allocation. Do you think it is better to have the code with inside an #ifdef instead of using the IS_ENABLED primitive? [1] https://lore.kernel.org/linux-fsdevel/20250516101054.676046-2-p.raghav@samsung.com/ -- Pankaj