Re: [v2 PATCH 1/1] fs/proc: Expose mm_cpumask in /proc/[pid]/status
From: David Hildenbrand (Red Hat)
Date: Tue Jan 06 2026 - 13:54:58 EST
On 1/1/26 02:19, Aaron Tomlin wrote:
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-specificHi David,
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
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.
Yes, starting with a very restrictive set, and carefully documenting it sounds good to me.
One question is what would happen if these semantics one day change on x86. I guess best we can do is to ... document it very carefully.
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.
Something along these lines. Maybe we want an CONFIG_ARCH_* define to unlock this from arch code.
--
Cheers
David