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 C5C7AC3ABD8 for ; Fri, 16 May 2025 14:03:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD2FE6B0183; Fri, 16 May 2025 10:02:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A827C6B0184; Fri, 16 May 2025 10:02:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9491D6B0185; Fri, 16 May 2025 10:02:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 76DFF6B0183 for ; Fri, 16 May 2025 10:02:59 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 49F3C5A600 for ; Fri, 16 May 2025 14:03:00 +0000 (UTC) X-FDA: 83448937320.26.2F55B8A Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by imf09.hostedemail.com (Postfix) with ESMTP id 608C714001F for ; Fri, 16 May 2025 14:02:56 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fnpLmJEG; spf=none (imf09.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747404178; a=rsa-sha256; cv=none; b=8Z3iQMGnItK3R/K8hebTC5VYoCxNIg54+hnh8AlVhA3i2YIaoCBSY1EB7wT9UEzA+IB62P oSet/xOMF63zRjCb16ZBCPC+Vq9XSkVySOUb15pCtqDk13GDnFJNQjFXtZVzE1oXolBvwX HBrD7t1Evx9pNt9mAnSY3nwOP8DQUhQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=fnpLmJEG; spf=none (imf09.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.15) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747404178; 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=GeudxfZdgsmjYp+vxV9ScInvRwfDy4Zr1FZKXAGc0B8=; b=r8J2+zmojsGvEHGdtrJfP2E4MAUZJS1jrp0PEONeT7+Kyl+jjnSmjxKenSx7qUcaXoG3/e pm/Lj8YsMkOSVGHpqtFR66Nex7yzjELzxwvCJEwL9RsqodVENr8H7NKIdlDlkOOJE0Y5aZ Oe88xseZc2yzpxgUtIDnNWov7vivv/8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1747404178; x=1778940178; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=XD5LW1X8Za8qYgmHHCMJojUWKp2P7yuhRCd7itD26lo=; b=fnpLmJEGLeTjrt0JppYnimY1f97uru+Grq5yvkNZLe6AbseQtNg7wHhl pbBRlH8TZ4kS2MRlPtmu9HZ2oOpZWZ3Krm7BgpPogdMGITDRDKJe5AbBD PGrTCJ2qLtXT3JYajs54MlN5QTc+nFtHKdmczLCq0+2smcSvkyV7f+enr HSdYmPAr3GsvmckHaF7NcCpLDfgH4X0/j9Fyebk/VziHo3M8UOuszwjf5 JPxoveAHGRVnMI/WGW+khPC4cSickRQyFm9pyG1bU+PvNHekMAgqsVLWl bowZw4Uoga/XGf7wwFLId+sn6WIzZ5U6RBq4C+HDqb5P2GclD7yCopU2L A==; X-CSE-ConnectionGUID: DWbcOlM6R8+Z9dscvOS98Q== X-CSE-MsgGUID: iK0qgsryQ5Sao34aVuQocg== X-IronPort-AV: E=McAfee;i="6700,10204,11435"; a="53049004" X-IronPort-AV: E=Sophos;i="6.15,293,1739865600"; d="scan'208";a="53049004" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2025 07:01:48 -0700 X-CSE-ConnectionGUID: ZTRg3ApCQOeOOdReIf9O4g== X-CSE-MsgGUID: OLEkQDUZR2y+jHsqHAwl6A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,293,1739865600"; d="scan'208";a="139101238" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa008.fm.intel.com with ESMTP; 16 May 2025 07:01:42 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 0FE981BC; Fri, 16 May 2025 17:01:20 +0300 (EEST) Date: Fri, 16 May 2025 17:01:20 +0300 From: "Kirill A. Shutemov" To: Dave Hansen Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Jonathan Corbet , Andy Lutomirski , Peter Zijlstra , Ard Biesheuvel , Jan Kiszka , Kieran Bingham , Michael Roth , Rick Edgecombe , Brijesh Singh , Sandipan Das , Juergen Gross , Tom Lendacky , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv3 2/4] x86/64/mm: Make SPARSEMEM_VMEMMAP the only memory model Message-ID: References: <20250516123306.3812286-1-kirill.shutemov@linux.intel.com> <20250516123306.3812286-3-kirill.shutemov@linux.intel.com> <30570ca0-8da4-4ebc-84d6-0a4badfb7154@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30570ca0-8da4-4ebc-84d6-0a4badfb7154@intel.com> X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 608C714001F X-Stat-Signature: r8kurhta717k89wjcrrc7uqk1n4o5x8k X-HE-Tag: 1747404176-686026 X-HE-Meta: U2FsdGVkX192RiV2BFKk4ubKn4okVbUN8H9LSENcWs/IoNUawzlKLUh2mr0x8Z7eHAiAzI+3nBXWT7U7RPADKGQggxS0TOIPJJ8fEV+wgjriIT7w0A30XuQ3g0WtJ4ZJPDQt3viVY8oUhSQPGXgv4RSXe5ccJNeX5uwn/6HdGXNUnI52MCU6vEKd0XN0S0X+AA+wCDJNmMwVwd73ne3yfOozguOfrPFai9dPBrnFAX2IM5sMDBhZ1Yo7arjvQU7roDCX/pCT+yAPzjFuIUVNDES8/s6+5u3wXRsRoWQ2eUJPtvT8ffP2wtFPmfKdpclTZSxKxDX9LVlgA84jKGkYpr4ctliYlggnhWdYbmxni8NhREeimRDF73HAFSAvKSRbv9ghmQgBHMD74qem0HRrxaFfrlMBPu65OB+WMea27w1HCx2gAB8AdsoQ3TbWAEuZ7Qbva2yRg0O77bg6nl8nxkRemCaxQ5e709XwSKtnx8YAN6fJalQWzbx42ul2TR0WbDVK6BefNuYXpdXLZ/Xr7cb0h8ozPUjpanP/x8tkPCXJKARAGOfyOsojEuOW+maS2+0gbQ6F9+3felf8kAtVnR9j3Y5Xk0l+9uZqixGuAgPx71w8aEThvCs6qCgnv97B8/fA06CrC7S55YYQBCqXOaTq2j1xvuowOgqSU1VMHArTRgGqxItkBi8pObseNjfawrNgqYyBJ54nW2fp+E1H5N7868e7UU3wgjxHqY7ZbMR6nbCh4r7bZDJNkATn1sb9jaYumtaAU4fFwzPyqQtPHIpvbJSBV7/Q5VcspDsXtWHLClt0C2FeFgqq1Nuc4v/8PBDIIj3eF1kRZXbL9Ekk5PibiFfCy6l4DXZyXyFfaDW1N/eZ4heb8kEznZRRB0M4szGtkWEdb/SOXN/GTECl+XTXCNa3T4/XMCmN3Lhg7mZ/61k9dO+/SYJcphbFfJiP7wGEilwtcNXhygvrjgj qUw0hf2v 4TnFFGqF37kqzcSH72ilu0EwzGWsik/CQoAbPziEDXfpJWP1yWOYegm18Q7Lt/gbrYT1Gavk9vJWNwf/Dsop9Ob/YOgrXjh3d+UZnSoY83iFFKcV3yTjJFgH/4uDhFMN+qo6P8ADI7/tigUXT/ff4WG+FhKif4Z2B6Yjb7bqmH1SHOJk+fzpPQKMKvcN0DhckSP7xpVKdrMoQ3D+FhkhLfiRjGMi4syCKltAlDblr5OZpNFs= 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 06:42:03AM -0700, Dave Hansen wrote: > On 5/16/25 05:33, Kirill A. Shutemov wrote: > > 5-level paging only supports SPARSEMEM_VMEMMAP. CONFIG_X86_5LEVEL is > > being phased out, making 5-level paging support mandatory. > > > > Make CONFIG_SPARSEMEM_VMEMMAP mandatory for x86-64 and eliminate > > any associated conditional statements. > I think we have ourselves a catch-22 here. > > SPARSEMEM_VMEMMAP was selected because the other sparsemem modes > couldn't handle a dynamic MAX_PHYS{MEM,ADDR}_BITS introduced by 5-level > paging. Now you're proposing making it static again, but keeping the > SPARSEMEM_VMEMMAP dependency. > > If you remove the dynamic MAX_PHYS{MEM,ADDR}_BITS, you should also > remove the dependency on SPARSEMEM_VMEMMAP. No? I guess. But how? And is there any value to support !SPARSEMEM_VMEMMAP? -- Kiryl Shutsemau / Kirill A. Shutemov