linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	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,
		mingo@kernel.org
Subject: Re: [PATCH v13 07/14] x86/mm: global ASID allocation helper functions
Date: Tue, 25 Feb 2025 15:22:30 -0500	[thread overview]
Message-ID: <b24e6e4dbf4b4f51fb564b848c01156237bd663c.camel@surriel.com> (raw)
In-Reply-To: <20250224141601.GIZ7x_IXs-wla5BRsd@fat_crate.local>

On Mon, 2025-02-24 at 15:16 +0100, Borislav Petkov wrote:
> On Sun, Feb 23, 2025 at 02:48:57PM -0500, Rik van Riel wrote:
> > 
> >  arch/x86/include/asm/mmu.h      |  11 +++
> >  arch/x86/include/asm/tlbflush.h |  43 ++++++++++
> >  arch/x86/mm/tlb.c               | 144
> > +++++++++++++++++++++++++++++++-
> >  3 files changed, 195 insertions(+), 3 deletions(-)
> 
> arch/x86/mm/tlb.c:378:6: warning: no previous prototype for
> ‘destroy_context_free_global_asid’ [-Wmissing-prototypes]
>   378 | void destroy_context_free_global_asid(struct mm_struct *mm)
>       |      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> arch/x86/mm/tlb.c:355:13: warning: ‘use_global_asid’ defined but not
> used [-Wunused-function]
>   355 | static void use_global_asid(struct mm_struct *mm)
>       |             ^~~~~~~~~~~~~~~
> arch/x86/mm/tlb.c:327:13: warning: ‘mm_active_cpus_exceeds’ defined
> but not used [-Wunused-function]
>   327 | static bool mm_active_cpus_exceeds(struct mm_struct *mm, int
> threshold)
>       |             ^~~~~~~~~~~~~~~~~~~~~~
> 
> If those functions are going to remain global they better get a
> proper prefix
> like "tlb_".
> 
I've renamed the global function to 
tlb_destroy_context_free_global_asid

> And add the functions with their first use - no need to pre-add them.

That's what I originally had. Dave requested I split
out the patch into multiple ones.

That means either introducing helper functions in a
separate patch, or coming up with one version of the
code in one patch, and then replacing that code in
the next, resulting in a bunch of extra code to review.

https://lore.kernel.org/linux-kernel/b067a9fc-ff5f-4baa-a1ff-3fa749ae4d44@intel.com/
> 
> > 
> > +static inline void assign_mm_global_asid(struct mm_struct *mm, u16
> > asid)
> 
> mm_assign_global_asid()

Done.

> > +/*
> > + * Global ASIDs are allocated for multi-threaded processes that
> > are
> > + * active on multiple CPUs simultaneously, giving each of those
> > + * processes the same PCIDs on every CPU, for use with hardware-
> > assisted
> 
> "the same PCID" or "the same PCIDs"?
> 
> Does a multithreaded process get one or more than one PCIDs? I'd
> expect only
> one ofc.

It's only one. Fixed the commment.

> 
> > +	asid = find_next_zero_bit(global_asid_used,
> > MAX_ASID_AVAILABLE, last_global_asid);
> > +
> > +	if (asid >= MAX_ASID_AVAILABLE) {
> 
> 	if (asid >= MAX_ASID_AVAILABLE && !global_asid_available)

Done.

> > +/*
> > + * Check whether a process is currently active on more than
> > "threshold" CPUs.
> 
> @threshold - then it is clear that you mean the function argument.
> 
Done. Thank you.

> > + * This is a cheap estimation on whether or not it may make sense
> > to assign
> > + * a global ASID to this process, and use broadcast TLB
> > invalidation.
> > + */
> > +static bool mm_active_cpus_exceeds(struct mm_struct *mm, int
> > threshold)
> > +{
> > +	int count = 0;
> > +	int cpu;
> 
> Is this function supposed to hold some sort of a lock?

I don't think we care too much about total accuracy here.

Not holding up other CPUs is probably more important.

> 
> > +
> > +	/* This quick check should eliminate most single threaded
> > programs. */
> > +	if (cpumask_weight(mm_cpumask(mm)) <= threshold)
> > +		return false;
> > +
> > +	/* Slower check to make sure. */
> > +	for_each_cpu(cpu, mm_cpumask(mm)) {
> 
> Needs CPU hotplug protection?

I don't see CPU hotplug protection in most other loops
that iterate over CPUs and do nothing but read some
per-CPU data.

What are we trying to protect against?

What kind of protection do we need?

> 
> > +	/* The last global ASID was consumed while waiting for the
> > lock. */
> > +	if (!global_asid_available) {
> > +		VM_WARN_ONCE(1, "Ran out of global ASIDs\n");
> 
> And? Why do we want to warn here? We need to reset global ASIDs
> anyway.

This warning prints if we run out of global ASIDs,
but have more processes in the system that want one.

This basically helps us figure out whether or not
we should bother implementing more aggressive ASID
re-use (like ARM and RISCV have), which might
require us to figure out how to make that re-use
more scalable than it is today.

> 
> > +		return;
> > +	}
> > +
> > +	asid = allocate_global_asid();
> > +	if (!asid)
> > +		return;
> > +
> > +	assign_mm_global_asid(mm, asid);
> > +}
> > +
> > +void destroy_context_free_global_asid(struct mm_struct *mm)
> 
> That name is a mouthful. mm_free_global_asid() is just fine.
> 
Done.

-- 
All Rights Reversed.


  reply	other threads:[~2025-02-25 20:23 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-23 19:48 [PATCH v13 00/14] AMD broadcast TLB invalidation Rik van Riel
2025-02-23 19:48 ` [PATCH v13 01/14] x86/mm: consolidate full flush threshold decision Rik van Riel
2025-02-24 11:48   ` Borislav Petkov
2025-02-23 19:48 ` [PATCH v13 02/14] x86/mm: get INVLPGB count max from CPUID Rik van Riel
2025-02-24 12:00   ` Borislav Petkov
2025-02-23 19:48 ` [PATCH v13 03/14] x86/mm: add INVLPGB support code Rik van Riel
2025-02-24 12:14   ` Borislav Petkov
2025-02-23 19:48 ` [PATCH v13 04/14] x86/mm: use INVLPGB for kernel TLB flushes Rik van Riel
2025-02-24 12:31   ` Borislav Petkov
2025-02-24 12:44     ` Nadav Amit
2025-02-23 19:48 ` [PATCH v13 05/14] x86/mm: use INVLPGB in flush_tlb_all Rik van Riel
2025-02-24 12:46   ` Borislav Petkov
2025-02-23 19:48 ` [PATCH v13 06/14] x86/mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2025-02-24 13:27   ` Borislav Petkov
2025-02-25 19:17     ` Rik van Riel
2025-02-25 20:38       ` Borislav Petkov
2025-02-25 21:03         ` Borislav Petkov
2025-02-25 22:03           ` Rik van Riel
2025-02-26 17:00           ` Tom Lendacky
2025-02-26 17:02             ` Rik van Riel
2025-02-26 17:36               ` Tom Lendacky
2025-02-26 17:46                 ` Rik van Riel
2025-02-26 18:12                   ` Tom Lendacky
2025-02-26 22:01                     ` Rik van Riel
2025-02-28  1:13                     ` Rik van Riel
2025-02-28 15:02                       ` Tom Lendacky
2025-02-28 15:57                         ` Sean Christopherson
2025-02-28 20:42                         ` Tom Lendacky
2025-02-23 19:48 ` [PATCH v13 07/14] x86/mm: global ASID allocation helper functions Rik van Riel
2025-02-24 14:16   ` Borislav Petkov
2025-02-25 20:22     ` Rik van Riel [this message]
2025-02-23 19:48 ` [PATCH v13 08/14] x86/mm: global ASID context switch & TLB flush handling Rik van Riel
2025-02-23 23:08   ` kernel test robot
2025-02-24  1:26     ` Rik van Riel
2025-02-24  2:01     ` Rik van Riel
2025-02-24 18:41   ` kernel test robot
2025-02-23 19:48 ` [PATCH v13 09/14] x86/mm: global ASID process exit helpers Rik van Riel
2025-02-23 19:49 ` [PATCH v13 10/14] x86/mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2025-02-23 19:49 ` [PATCH v13 11/14] x86/mm: do targeted broadcast flushing from tlbbatch code Rik van Riel
2025-02-23 19:49 ` [PATCH v13 12/14] x86/mm: enable AMD translation cache extensions Rik van Riel
2025-02-23 19:49 ` [PATCH v13 13/14] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2025-02-23 19:49 ` [PATCH v13 14/14] x86/mm: add noinvlpgb commandline option Rik van Riel
2025-02-23 21:29   ` Borislav Petkov
2025-02-24  0:34     ` Rik van Riel
2025-02-24  6:29       ` 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=b24e6e4dbf4b4f51fb564b848c01156237bd663c.camel@surriel.com \
    --to=riel@surriel.com \
    --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=mingo@kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=peterz@infradead.org \
    --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