From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0718C158533 for ; Thu, 23 Jan 2025 17:24:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737653083; cv=none; b=fiQBSMLN1AgRNcp+D8ggeiXbr8OkRagywTUYz2wEQxP38lQj907L/pKmPD3/nETMvE2ELljALu1LHsjCZL4BrCK+e9G5sEMpzksuV/v5euOL6OTCBZVlkzakhpGuAwSHtjXANNy1zgdxpLhFqlo1ZdCesDEk8VwRgRnXVcrv3SY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737653083; c=relaxed/simple; bh=8lMj8lD9aNxf+N0uso5hNUYweVNz56JjbOkwe/Q2T+I=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=Z7TW3wt9JDogDTQT1Ib4ODrI9ljhH6cW3YCe/27JEkYlehHy78QWVFbX2Sc87LB7iHGD4onGbOH0Jwgt1BQFt9/N85ffkLT3T0/7m11liMiMeDuPrgtB1BvCuaI9J9ktp2wOojLYogwWLLKBNFMGPcMrz+MP6g9NgNW3kEdFamY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=RHSBAzsg; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="RHSBAzsg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1737653082; x=1769189082; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=8lMj8lD9aNxf+N0uso5hNUYweVNz56JjbOkwe/Q2T+I=; b=RHSBAzsgbW1Zxxa/twERZp1nYZgNMrUfhAwSv3duqPD2jQsWovuQTmEM 5S1s/b77T4Hsi3Ji3XsotQ4oCRmZ2u+i8y+b8ESuKlHrPKoJra8BM8K82 zfzqs0seOUZ8vV16cEXkYONilaTzP/4+zERsxZqfccFvsSNXeJTXJabaq 45YSeJzcCNZdV7pG8BDFBKK+GSMNhMCN4hax0xOhCJPf1ejzm3mxcwBiF +uFCg80X6veBRaqg2vZxH+gFXxRF42iOvm3i2Y4BoMYSnyS6WyjnM9TWA LdofsP2FWrQkPeBYuxnS0g0SnRpglG3s1o651e6CzsG11ijQJ0cVN99dY Q==; X-CSE-ConnectionGUID: o0jlOo4iQNqb+7iuRqZLqg== X-CSE-MsgGUID: 2InEpD1/Qdaqg45cigjrNw== X-IronPort-AV: E=McAfee;i="6700,10204,11314"; a="49583850" X-IronPort-AV: E=Sophos;i="6.12,310,1728975600"; d="scan'208";a="49583850" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2025 09:24:34 -0800 X-CSE-ConnectionGUID: 1cVHJggIS06avYdBt5m4fg== X-CSE-MsgGUID: L08ZfIhFRGqp5m42EGETCQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,229,1732608000"; d="scan'208";a="107649976" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa008.fm.intel.com with ESMTP; 23 Jan 2025 09:24:34 -0800 Subject: [RFC][PATCH 3/8] x86/mm: Always tell core mm to sync kernel mappings To: linux-kernel@vger.kernel.org Cc: x86@kernel.org,tglx@linutronix.de,bp@alien8.de,joro@8bytes.org,luto@kernel.org,peterz@infradead.org,kirill.shutemov@linux.intel.com,rick.p.edgecombe@intel.com,jgross@suse.com,Dave Hansen From: Dave Hansen Date: Thu, 23 Jan 2025 09:24:33 -0800 References: <20250123172428.D6D8C8D9@davehans-spike.ostc.intel.com> In-Reply-To: <20250123172428.D6D8C8D9@davehans-spike.ostc.intel.com> Message-Id: <20250123172433.73E60E6C@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: From: Dave Hansen Each mm_struct has its own copy of the page tables. When core mm code makes changes to a copy of the page tables those changes sometimes need to be synchronized with other mms' copies of the page tables. But when this synchronization actually needs to happen is highly architecture and configuration specific. In cases where kernel PMDs are shared across processes (SHARED_KERNEL_PMD) the core mm does not itself need to do that synchronization for kernel PMD changes. The x86 code communicates this by clearing the PGTBL_PMD_MODIFIED bit cleared in those configs to avoid expensive synchronization. The kernel is moving toward never sharing kernel PMDs on 32-bit. Prepare for that and make 32-bit PAE always set PGTBL_PMD_MODIFIED, even if there is no modification to synchronize. This obviously adds some synchronization overhead in cases where the kernel page tables are being changed. Signed-off-by: Dave Hansen --- b/arch/x86/include/asm/pgtable-3level_types.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN arch/x86/include/asm/pgtable-3level_types.h~always-set-ARCH_PAGE_TABLE_SYNC_MASK arch/x86/include/asm/pgtable-3level_types.h --- a/arch/x86/include/asm/pgtable-3level_types.h~always-set-ARCH_PAGE_TABLE_SYNC_MASK 2025-01-23 09:20:51.158365128 -0800 +++ b/arch/x86/include/asm/pgtable-3level_types.h 2025-01-23 09:20:51.162365272 -0800 @@ -29,7 +29,7 @@ typedef union { #define SHARED_KERNEL_PMD (!static_cpu_has(X86_FEATURE_PTI)) -#define ARCH_PAGE_TABLE_SYNC_MASK (SHARED_KERNEL_PMD ? 0 : PGTBL_PMD_MODIFIED) +#define ARCH_PAGE_TABLE_SYNC_MASK PGTBL_PMD_MODIFIED /* * PGDIR_SHIFT determines what a top-level page table entry can map _