Received-SPF: pass (google.com: domain of linux-kernel+bounces-172252-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Yang Shi <yang@os.amperecomputing.com>
To: catalin.marinas@arm.com,
	will@kernel.org,
	scott@os.amperecomputing.com,
	cl@gentwo.org
Cc: yang@os.amperecomputing.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH] arm64: mm: force write fault for atomic RMW instructions
Date: Tue,  7 May 2024 15:35:58 -0700
Message-ID: <20240507223558.3039562-1-yang@os.amperecomputing.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?GJdecM+Syvn75M+VY9URzuiA51p2E6Z8KfuS0SHlfTXFOi6Pk727pAtLwFha?=
 =?us-ascii?Q?urnCMFS6gWiXI1Mg6Z+PxAATZDT+fZICdsYdF+PuyrxjDWhxbK8trqdZfNT6?=
 =?us-ascii?Q?tHFtU/AziMtZDIVLxqPnMwe8bMcfTaYNu5+nd3bKBZyoDJPvOfNltjFOqA9U?=
 =?us-ascii?Q?JACJybNdqzxWU4eB70tV/OMg+3u8nubHcG6vkvf7TDjefQZse1YQb65fYW6D?=
 =?us-ascii?Q?f4PvgMBulcR2uhHbt+lSCpgLb/WFR0P9jt+/NFAy17eoXqn1FitVOzSAS5Rf?=
 =?us-ascii?Q?x3BYJpMeSZ3M1T1M+Ajkm7sHtjoLnbfOWscGe5jHF6fLd9JV1GurlycjGPzD?=
 =?us-ascii?Q?8KkqINct8AilXWi5rOnbuR/UOsTgSztmbM6OKQ9S2J9DbsiAQjoPpnhN8K3n?=
 =?us-ascii?Q?LnzZdtJlarOs2u+mNXa2LDKzDjST2u/0c0dsv20yCEVPqAsgWqU9tKRP4ry3?=
 =?us-ascii?Q?l+DlIA+2KSMYTgscJYk1Aih783lMbgh57MLEvUcD2g19MX4QkXwM0FiaAWbd?=
 =?us-ascii?Q?o9NL0fo+EyVQZVEzWOlCOKbaX3EQs3UD6gDdhdv1kwIPigVSDPVfMo5gWPSP?=
 =?us-ascii?Q?LqC+26aP6PNfVjUD5nyC22qrGaO+JAU1xryJVqS0zzh0CZAJUEqshfTZDEo6?=
 =?us-ascii?Q?T6BZxmClXy/Yf8mxClX+2w1qmZK610f4kuee3WhuW34KVcc8g3fmUDM3tSFk?=
 =?us-ascii?Q?Fq6+nUORwlJOm3vOG+BZyki+cCWVb7LJzOmBsiAi0ovzaAZY8SfpVdc7E4VB?=
 =?us-ascii?Q?ll/JLaeZ7HOeVzczpYceAGVS2Q5uxUxGifuG2qZZ1+nSBHk6NQkizo6IU0AU?=
 =?us-ascii?Q?H0ZbH6+gx+AEGszJS3riGchKNLr/zgTOMzFyE+dyscmp9zOkelGJILnbrDCv?=
 =?us-ascii?Q?dlGR0snKMnNmApGF9ihOB9tHWTtB2gaxlYrTkzoEgOMvu/Fb1jRSiBs3U0yy?=
 =?us-ascii?Q?UbjAznc7AVHvglMzfpZt06l3EvaPY8FgiBBIFf4xDW2DzwvPTbA3/p4Yp95k?=
 =?us-ascii?Q?1AgLyMU9XDrl3sv0kvc5Y/qJr9DxWPN7Q1t3xpH1H/pUOIL2H8qJIIV2zYpz?=
 =?us-ascii?Q?XNcladOkgpgyJ1rTFk9PWRr1F6HD19Eyyi03tzhzbnmoqW+6jjN3GUkiV68I?=
 =?us-ascii?Q?TUxsgjGoxqAGI8KRuoR7GlqXVubNORxysaP95ZJ+QP8NXfuSAHQFjPE2XM7l?=
 =?us-ascii?Q?Q7IzDmEl8CkDY0OznVDOkWh7dVhpUmHjPfiGBVR+tAlWlWS+u0eTEAy5cV0H?=
 =?us-ascii?Q?BtcOlKboEw60uzd4/oRETeWu6rOXieWsrfCFaqddvaBz/TS1y6XnDdhlOraW?=
 =?us-ascii?Q?+FDVhWTztUivb8/BZchDeWU6goC3+BgC5aRSj/yGHZhlByPJZ5q1vgAC8UK/?=
 =?us-ascii?Q?3lGStA1tVvjRRKj3F/xoTg/pTlusua0OfeEokQxtYC0pXyD/3BGvO4NX3IZz?=
 =?us-ascii?Q?vJ/PssiwG51UcNOxJTRJSmmlXNDqaZzs9DF/ecLxQ6hRAr0+pPJtBePfYmS9?=
 =?us-ascii?Q?F46UPoEe2x/gU0OxBxJD3oytE7qwL7MLamHasxNrAPmpYJ9iKRHWTOFxoDTV?=
 =?us-ascii?Q?34N8wyFiGjCfVMwz7QOiv7qHNEfchL76aOdOT0zs3fBS/b0ghQu2MoS6ZUrB?=
 =?us-ascii?Q?b5JO/LwP85NIGhO8mnOUo7c=3D?=
X-OriginatorOrg: os.amperecomputing.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f49a043-51b0-4da6-5666-08dc6ee61af1
X-MS-Exchange-CrossTenant-AuthSource: BYAPR01MB5463.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2024 22:36:15.5199
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: P0+hMGhzOsfYDdkjReFOo/bFb7AQuT1mIScicHsKyQwA3Yad4CJg7iWmi4mha0EA/rjb1Tx8DUht0ZZvMPiwaCLSneQD6SiMuycyUcCPshw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR01MB8291

The atomic RMW instructions, for example, ldadd, actually does load +
add + store in one instruction, it may trigger two page faults, the
first fault is a read fault, the second fault is a write fault.

Some applications use atomic RMW instructions to populate memory, for
example, openjdk uses atomic-add-0 to do pretouch (populate heap memory
at launch time) between v18 and v22.

But the double page fault has some problems:

1. Noticeable TLB overhead.  The kernel actually installs zero page with
   readonly PTE for the read fault.  The write fault will trigger a
   write-protection fault (CoW).  The CoW will allocate a new page and
   make the PTE point to the new page, this needs TLB invalidations.  The
   tlb invalidation and the mandatory memory barriers may incur
   significant overhead, particularly on the machines with many cores.

2. Break up huge pages.  If THP is on the read fault will install huge
   zero pages.  The later CoW will break up the huge page and allocate
   base pages instead of huge page.  The applications have to rely on
   khugepaged (kernel thread) to collapse huge pages asynchronously.
   This also incurs noticeable performance penalty.

3. 512x page faults with huge page.  Due to #2, the applications have to
   have page faults for every 4K area for the write, this makes the speed
   up by using huge page actually gone.

So it sounds pointless to have two page faults since we know the memory
will be definitely written very soon.  Forcing write fault for atomic RMW
instruction makes some sense and it can solve the aforementioned problems:

Firstly, it just allocates zero'ed page, no tlb invalidation and memory
barriers anymore.
Secondly, it can populate writable huge pages in the first place and
don't break them up.  Just one page fault is needed for 2M area instrad
of 512 faults and also save cpu time by not using khugepaged.

A simple micro benchmark which populates 1G memory shows the number of
page faults is reduced by half and the time spent by system is reduced
by 60% on a VM running on Ampere Altra platform.

And the benchmark for anonymous read fault on 1G memory, file read fault
on 1G file (cold page cache and warm page cache) don't show noticeable
regression.

Some other architectures also have code inspection in page fault path,
for example, SPARC and x86.

Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
---
 arch/arm64/include/asm/insn.h |  1 +
 arch/arm64/mm/fault.c         | 19 +++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index db1aeacd4cd9..5d5a3fbeecc0 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -319,6 +319,7 @@ static __always_inline u32 aarch64_insn_get_##abbr##_value(void)	\
  * "-" means "don't care"
  */
 __AARCH64_INSN_FUNCS(class_branch_sys,	0x1c000000, 0x14000000)
+__AARCH64_INSN_FUNCS(class_atomic,	0x3b200c00, 0x38200000)
 
 __AARCH64_INSN_FUNCS(adr,	0x9F000000, 0x10000000)
 __AARCH64_INSN_FUNCS(adrp,	0x9F000000, 0x90000000)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 8251e2fea9c7..f7bceedf5ef3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -529,6 +529,7 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
 	unsigned int mm_flags = FAULT_FLAG_DEFAULT;
 	unsigned long addr = untagged_addr(far);
 	struct vm_area_struct *vma;
+	unsigned int insn;
 
 	if (kprobe_page_fault(regs, esr))
 		return 0;
@@ -586,6 +587,24 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
 	if (!vma)
 		goto lock_mmap;
 
+	if (mm_flags & (FAULT_FLAG_WRITE | FAULT_FLAG_INSTRUCTION))
+		goto continue_fault;
+
+	pagefault_disable();
+
+	if (get_user(insn, (unsigned int __user *) instruction_pointer(regs))) {
+		pagefault_enable();
+		goto continue_fault;
+	}
+
+	if (aarch64_insn_is_class_atomic(insn)) {
+		vm_flags = VM_WRITE;
+		mm_flags |= FAULT_FLAG_WRITE;
+	}
+
+	pagefault_enable();
+
+continue_fault:
 	if (!(vma->vm_flags & vm_flags)) {
 		vma_end_read(vma);
 		goto lock_mmap;
-- 
2.41.0