From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: x86@kernel.org, Rik van Riel <riel@surriel.com>
Cc: linux-kernel@vger.kernel.org, bp@alien8.de, peterz@infradead.org,
dave.hansen@linux.intel.com, zhengqi.arch@bytedance.com,
nadav.amit@gmail.com, thomas.lendacky@amd.com,
kernel-team@meta.com, linux-mm@kvack.org,
akpm@linux-foundation.org, jackmanb@google.com, jannh@google.com,
mhklinux@outlook.com, andrew.cooper3@citrix.com,
Manali.Shukla@amd.com
Subject: Re: [PATCH v12 00/16] AMD broadcast TLB invalidation
Date: Sat, 22 Feb 2025 12:29:54 +0100 [thread overview]
Message-ID: <5861243.DvuYhMxLoT@natalenko.name> (raw)
In-Reply-To: <20250221005345.2156760-1-riel@surriel.com>
[-- Attachment #1: Type: text/plain, Size: 6940 bytes --]
Hello.
On pátek 21. února 2025 1:52:59, středoevropský standardní čas Rik van Riel wrote:
> Add support for broadcast TLB invalidation using AMD's INVLPGB instruction.
>
> This allows the kernel to invalidate TLB entries on remote CPUs without
> needing to send IPIs, without having to wait for remote CPUs to handle
> those interrupts, and with less interruption to what was running on
> those CPUs.
>
> Because x86 PCID space is limited, and there are some very large
> systems out there, broadcast TLB invalidation is only used for
> processes that are active on 3 or more CPUs, with the threshold
> being gradually increased the more the PCID space gets exhausted.
>
> Combined with the removal of unnecessary lru_add_drain calls
> (see https://lkml.org/lkml/2024/12/19/1388) this results in a
> nice performance boost for the will-it-scale tlb_flush2_threads
> test on an AMD Milan system with 36 cores:
>
> - vanilla kernel: 527k loops/second
> - lru_add_drain removal: 731k loops/second
> - only INVLPGB: 527k loops/second
> - lru_add_drain + INVLPGB: 1157k loops/second
>
> Profiling with only the INVLPGB changes showed while
> TLB invalidation went down from 40% of the total CPU
> time to only around 4% of CPU time, the contention
> simply moved to the LRU lock.
>
> Fixing both at the same time about doubles the
> number of iterations per second from this case.
>
> Some numbers closer to real world performance
> can be found at Phoronix, thanks to Michael:
>
> https://www.phoronix.com/news/AMD-INVLPGB-Linux-Benefits
>
> My current plan is to implement support for Intel's RAR
> (Remote Action Request) TLB flushing in a follow-up series,
> after this thing has been merged into -tip. Making things
> any larger would just be unwieldy for reviewers.
>
> v12:
> - make sure "nopcid" command line option turns off invlpgb (Brendan)
> - add "noinvlpgb" kernel command line option
> - split out kernel TLB flushing differently (Dave & Yosry)
> - split up the patch that does invlpgb flushing for user processes (Dave)
> - clean up get_flush_tlb_info (Boris)
> - move invlpgb_count_max initialization to get_cpu_cap (Boris)
> - bunch more comments as requested
Somehow, this iteration breaks resume from S3. I can see it even in a QEMU VM:
```
[ 24.373391] ACPI: PM: Low-level resume complete
[ 24.373929] ACPI: PM: Restoring platform NVS memory
[ 24.375024] Enabling non-boot CPUs ...
[ 24.375777] smpboot: Booting Node 0 Processor 1 APIC 0x1
[ 24.376463] BUG: unable to handle page fault for address: ffffffffa3ba4d60
[ 24.377383] #PF: supervisor write access in kernel mode
[ 24.377912] #PF: error_code(0x0003) - permissions violation
[ 24.378413] PGD 25427067 P4D 25427067 PUD 25428063 PMD 8000000024c001a1
[ 24.379020] Oops: Oops: 0003 [#1] PREEMPT SMP NOPTI
[ 24.379503] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Kdump: loaded Not tainted 6.14.0-pf0 #1 161e4891fb5044b2d7438cd1852eeaac0cdffab5
[ 24.380650] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
[ 24.381400] RIP: 0010:get_cpu_cap+0x39b/0x4f0
[ 24.381810] Code: 08 c7 44 24 08 00 00 00 00 48 8d 4c 24 0c e8 3c 00 04 00 90 8b 44 24 04 89 43 64 0f b7 44 24 0c 83 c0 01 81 7b 24 09 00 00 80 <66> 89 05 0e ab 8b 01 0f 86 18 fd ff ff c7 44 24 14 00 00 00 00 4c
[ 24.383629] RSP: 0000:ffffafbec00efe70 EFLAGS: 00010012
[ 24.384155] RAX: 0000000000000001 RBX: ffff8b3fbcb19020 RCX: 0000000000001001
[ 24.384862] RDX: 0000000000000000 RSI: ffffafbec00efe74 RDI: ffffafbec00efe78
[ 24.385603] RBP: ffffafbec00efe88 R08: ffffafbec00efe70 R09: ffffafbec00efe7c
[ 24.386318] R10: 0000000000002430 R11: ffff8b3fa5428000 R12: ffffafbec00efe8c
[ 24.387014] R13: ffffafbec00efe84 R14: ffffafbec00efe80 R15: ffffafbec00efe70
[ 24.387713] FS: 0000000000000000(0000) GS:ffff8b3fbcb00000(0000) knlGS:0000000000000000
[ 24.388502] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 24.389074] CR2: ffffffffa3ba4d60 CR3: 0000000025422000 CR4: 0000000000350ef0
[ 24.389769] Call Trace:
[ 24.390020] <TASK>
[ 24.392234] identify_cpu+0xd4/0x890
[ 24.392593] identify_secondary_cpu+0x12/0x40
[ 24.393032] smp_store_cpu_info+0x49/0x60
[ 24.393430] start_secondary+0x7f/0x140
[ 24.393810] common_startup_64+0x13e/0x141
[ 24.394218] </TASK>
$ scripts/faddr2line arch/x86/kernel/cpu/common.o get_cpu_cap+0x39b
get_cpu_cap+0x39b/0x500:
get_cpu_cap at …/arch/x86/kernel/cpu/common.c:1063
1060 if (c->extended_cpuid_level >= 0x80000008) {
1061 cpuid(0x80000008, &eax, &ebx, &ecx, &edx);
1062 c->x86_capability[CPUID_8000_0008_EBX] = ebx;
1063 invlpgb_count_max = (edx & 0xffff) + 1;
1064 }
```
Any idea what I'm looking at?
Thank you.
> v11:
> - resolve conflict with CONFIG_PT_RECLAIM code
> - a few more cleanups (Peter, Brendan, Nadav)
> v10:
> - simplify partial pages with min(nr, 1) in the invlpgb loop (Peter)
> - document x86 paravirt, AMD invlpgb, and ARM64 flush without IPI (Brendan)
> - remove IS_ENABLED(CONFIG_X86_BROADCAST_TLB_FLUSH) (Brendan)
> - various cleanups (Brendan)
> v9:
> - print warning when start or end address was rounded (Peter)
> - in the reclaim code, tlbsync at context switch time (Peter)
> - fix !CONFIG_CPU_SUP_AMD compile error in arch_tlbbatch_add_pending (Jan)
> v8:
> - round start & end to handle non-page-aligned callers (Steven & Jan)
> - fix up changelog & add tested-by tags (Manali)
> v7:
> - a few small code cleanups (Nadav)
> - fix spurious VM_WARN_ON_ONCE in mm_global_asid
> - code simplifications & better barriers (Peter & Dave)
> v6:
> - fix info->end check in flush_tlb_kernel_range (Michael)
> - disable broadcast TLB flushing on 32 bit x86
> v5:
> - use byte assembly for compatibility with older toolchains (Borislav, Michael)
> - ensure a panic on an invalid number of extra pages (Dave, Tom)
> - add cant_migrate() assertion to tlbsync (Jann)
> - a bunch more cleanups (Nadav)
> - key TCE enabling off X86_FEATURE_TCE (Andrew)
> - fix a race between reclaim and ASID transition (Jann)
> v4:
> - Use only bitmaps to track free global ASIDs (Nadav)
> - Improved AMD initialization (Borislav & Tom)
> - Various naming and documentation improvements (Peter, Nadav, Tom, Dave)
> - Fixes for subtle race conditions (Jann)
> v3:
> - Remove paravirt tlb_remove_table call (thank you Qi Zheng)
> - More suggested cleanups and changelog fixes by Peter and Nadav
> v2:
> - Apply suggestions by Peter and Borislav (thank you!)
> - Fix bug in arch_tlbbatch_flush, where we need to do both
> the TLBSYNC, and flush the CPUs that are in the cpumask.
> - Some updates to comments and changelogs based on questions.
>
>
>
--
Oleksandr Natalenko, MSE
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2025-02-22 11:30 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 0:52 Rik van Riel
2025-02-21 0:53 ` [PATCH v12 01/16] x86/mm: make MMU_GATHER_RCU_TABLE_FREE unconditional Rik van Riel
2025-02-21 0:53 ` [PATCH v12 02/16] x86/mm: remove pv_ops.mmu.tlb_remove_table call Rik van Riel
2025-02-21 0:53 ` [PATCH v12 03/16] x86/mm: consolidate full flush threshold decision Rik van Riel
2025-02-21 0:53 ` [PATCH v12 04/16] x86/mm: get INVLPGB count max from CPUID Rik van Riel
2025-02-21 1:58 ` Borislav Petkov
2025-02-21 2:25 ` Rik van Riel
2025-02-21 18:03 ` [PATCH v12.1 " Rik van Riel
2025-02-21 18:41 ` Tom Lendacky
2025-02-22 3:35 ` [PATCH v12.2 " Rik van Riel
2025-02-21 0:53 ` [PATCH v12 05/16] x86/mm: add INVLPGB support code Rik van Riel
2025-02-21 0:53 ` [PATCH v12 06/16] x86/mm: use INVLPGB for kernel TLB flushes Rik van Riel
2025-02-21 0:53 ` [PATCH v12 07/16] x86/mm: use INVLPGB in flush_tlb_all Rik van Riel
2025-02-21 0:53 ` [PATCH v12 08/16] x86/mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2025-02-21 0:53 ` [PATCH v12 09/16] x86/mm: global ASID allocation helper functions Rik van Riel
2025-02-21 0:53 ` [PATCH v12 10/16] x86/mm: global ASID context switch & TLB flush handling Rik van Riel
2025-02-21 0:53 ` [PATCH v12 11/16] x86/mm: global ASID process exit helpers Rik van Riel
2025-02-21 0:53 ` [PATCH v12 12/16] x86/mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2025-02-21 0:53 ` [PATCH v12 13/16] x86/mm: do targeted broadcast flushing from tlbbatch code Rik van Riel
2025-02-21 0:53 ` [PATCH v12 14/16] x86/mm: enable AMD translation cache extensions Rik van Riel
2025-02-21 0:53 ` [PATCH v12 15/16] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2025-02-21 0:53 ` [PATCH v12 16/16] x86/mm: add noinvlpgb commandline option Rik van Riel
2025-02-22 11:29 ` Oleksandr Natalenko [this message]
2025-02-22 11:36 ` [PATCH v12 00/16] AMD broadcast TLB invalidation Oleksandr Natalenko
2025-02-22 16:05 ` Rik van Riel
2025-02-22 16:19 ` Borislav Petkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5861243.DvuYhMxLoT@natalenko.name \
--to=oleksandr@natalenko.name \
--cc=Manali.Shukla@amd.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=jackmanb@google.com \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhklinux@outlook.com \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=zhengqi.arch@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox