Re: [v2 PATCH 1/1] fs/proc: Expose mm_cpumask in /proc/[pid]/status

[Aaron Tomlin]

On Tue, Dec 30, 2025 at 10:16:30PM +0100, David Hildenbrand (Red Hat) wrote:
> Just a note: I have the faint recollection that there are some arch-specific
> oddities around mm_cpumask().
> 
> In particular, that some architectures never clear CPUs from the mask, while
> others (e.g., x86) clear them one the TLB for them is clean.
> 
> I'd assume that all architectures at least set the CPUs once they ever ran
> an MM. But are we sure about that?
> 
> $ git grep mm_cpumask | grep m68k
> 
> gives me no results and I don't see common code to ever set a cpu in
> the mm_cpumask.
> 
> -- 
> Cheers
> 
Hi David,

You are correct; mm_cpumask semantics vary across architectures (e.g., arc)
and are even unused on some (e.g., m68k).

Rather than attempting to standardise this across all architectures, I
propose we restrict this information to those that follow the "Lazy" TLB
model-specifically x86. In this model, the mask represents CPUs that might
hold stale TLB entries for a given MM and thus require IPI-based TLB
shootdowns to maintain coherency. Since this is the primary context where
mm_cpumask provides actionable debug data for performance bottlenecks,
showing it only for x86 (where it is reliably maintained) seems the most
pragmatic path.

I can document this arch-specific limitation in
Documentation/filesystems/proc.rst and wrapped the implementation in
CONFIG_X86 to avoid exposing "Best Effort" or zeroed-out data on
architectures where the mask is not meaningful.

Please let me know your thoughts.


Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature