From: Nadav Amit <nadav.amit@gmail.com>
To: Rik van Riel <riel@surriel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
the arch/x86 maintainers <x86@kernel.org>,
kernel-team@meta.com, Dave Hansen <dave.hansen@linux.intel.com>,
luto@kernel.org, peterz@infradead.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Yu-cheng Yu <yu-cheng.yu@intel.com>
Subject: Re: [RFC PATCH 7/9] x86/mm: Introduce Remote Action Request
Date: Tue, 6 May 2025 09:59:52 +0300 [thread overview]
Message-ID: <03E5F4D7-3E3F-4809-87FE-6BD0B792E90F@gmail.com> (raw)
In-Reply-To: <20250506003811.92405-8-riel@surriel.com>
> On 6 May 2025, at 3:37, Rik van Riel <riel@surriel.com> wrote:
>
> +void smp_call_rar_many(const struct cpumask *mask, u16 pcid,
> + unsigned long start, unsigned long end)
> +{
> + unsigned long pages = (end - start + PAGE_SIZE) / PAGE_SIZE;
> + int cpu, next_cpu, this_cpu = smp_processor_id();
> + cpumask_t *dest_mask;
> + unsigned long idx;
> +
> + if (pages > RAR_INVLPG_MAX_PAGES || end == TLB_FLUSH_ALL)
> + pages = RAR_INVLPG_MAX_PAGES;
> +
> + /*
> + * Can deadlock when called with interrupts disabled.
> + * We allow cpu's that are not yet online though, as no one else can
> + * send smp call function interrupt to this cpu and as such deadlocks
> + * can't happen.
> + */
> + WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
> + && !oops_in_progress && !early_boot_irqs_disabled);
To ease it for the reader, consider using the updated version from smp.c
(or - even better - refactor into common inline function):
if (cpu_online(this_cpu) && !oops_in_progress &&
!early_boot_irqs_disabled)
lockdep_assert_irqs_enabled();
> +
> + /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */
> + cpu = cpumask_first_and(mask, cpu_online_mask);
> + if (cpu == this_cpu)
> + cpu = cpumask_next_and(cpu, mask, cpu_online_mask);
> +
> + /* No online cpus? We're done. */
> + if (cpu >= nr_cpu_ids)
> + return;
> +
> + /* Do we have another CPU which isn't us? */
> + next_cpu = cpumask_next_and(cpu, mask, cpu_online_mask);
> + if (next_cpu == this_cpu)
> + next_cpu = cpumask_next_and(next_cpu, mask, cpu_online_mask);
> +
> + /* Fastpath: do that cpu by itself. */
If you follow my comment (suggestion) about the concurrent flushes, then
this part should be moved to be in the same was as done in the updated
smp_call_function_many_cond().
IOW, the main difference between this path and the “slow path” is
arch_send_rar_ipi_mask() vs arch_send_rar_single_ipi() (and maybe
“and” with cpu_online_mask).
> + if (next_cpu >= nr_cpu_ids) {
> + lock(this_cpu_ptr(&rar_lock));
> + idx = get_payload();
> + set_payload(idx, pcid, start, pages);
> + set_action_entry(idx, cpu);
> + arch_send_rar_single_ipi(cpu);
> + wait_for_done(idx, cpu);
> + free_payload(idx);
> + unlock(this_cpu_ptr(&rar_lock));
> + return;
> + }
> +
> + dest_mask = this_cpu_ptr(&rar_cpu_mask);
> + cpumask_and(dest_mask, mask, cpu_online_mask);
> + cpumask_clear_cpu(this_cpu, dest_mask);
> +
> + /* Some callers race with other cpus changing the passed mask */
> + if (unlikely(!cpumask_weight(dest_mask)))
> + return;
> +
> + lock(this_cpu_ptr(&rar_lock));
> + idx = get_payload();
> + set_payload(idx, pcid, start, pages);
> +
> + for_each_cpu(cpu, dest_mask)
> + set_action_entry(idx, cpu);
> +
> + /* Send a message to all CPUs in the map */
> + arch_send_rar_ipi_mask(dest_mask);
Since 2019 we have move into “multi” TLB flush instead of “many”.
This means that try to take advantage of the time between sending the IPI
and the indication it was completed to do the local TLB flush. For both
consistency and performance, I recommend you’d follow this approach and
do the local TLB flush (if needed) here, instead of doing it in the
caller.
> +
> + for_each_cpu(cpu, dest_mask)
> + wait_for_done(idx, cpu);
> +
> + free_payload(idx);
> + unlock(this_cpu_ptr(&rar_lock));
We don’t do lock/unlock on kernel/smp.c . So I would expect at least a
comment as for why it is required.
> +}
> +EXPORT_SYMBOL(smp_call_rar_many);
next prev parent reply other threads:[~2025-05-06 7:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-06 0:37 [RFC PATCH 0/9] Intel RAR TLB invalidation Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 1/9] x86/mm: Introduce MSR_IA32_CORE_CAPABILITIES Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 2/9] x86/mm: Introduce Remote Action Request MSRs Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 3/9] x86/mm: enable BROADCAST_TLB_FLUSH on Intel, too Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 4/9] x86/mm: Introduce X86_FEATURE_RAR Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 5/9] x86/mm: Change cpa_flush() to call flush_kernel_range() directly Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 6/9] x86/apic: Introduce Remote Action Request Operations Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 7/9] x86/mm: Introduce Remote Action Request Rik van Riel
2025-05-06 6:59 ` Nadav Amit [this message]
2025-05-06 15:16 ` Rik van Riel
2025-05-06 15:27 ` Dave Hansen
2025-05-06 15:50 ` Nadav Amit
2025-05-06 16:00 ` Rik van Riel
2025-05-06 16:31 ` Ingo Molnar
2025-05-06 0:37 ` [RFC PATCH 8/9] x86/mm: use RAR for kernel TLB flushes Rik van Riel
2025-05-06 0:37 ` [RFC PATCH 9/9] x86/mm: userspace & pageout flushing using Intel RAR Rik van Riel
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=03E5F4D7-3E3F-4809-87FE-6BD0B792E90F@gmail.com \
--to=nadav.amit@gmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.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