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

[Aaron Tomlin]

On Wed, Dec 17, 2025 at 06:33:26PM +0100, Oleg Nesterov wrote:
> Can't really comment this patch... I mean the intent.
> Just a couple of nits:

Hi Oleg,

Long time no speak. Thank you for your response.

> 	- I think this patch should also update
> 	Documentation/filesystems/proc.rst

Acknowledged. I will do so in the follow-up patch.

> 	- I won't object, but do we really need/want another "if (mm)" block ?

I appreciate your observation; technically, the code could be more compact
by merging this into the earlier conditional block. However, my reasoning
here was primarily a personal preference regarding the resulting output of
/proc/[PID]/status. I felt it was beneficial to keep "Cpus_active_mm" and
"Cpus_active_mm_list" in close proximity to their counterparts,
"Cpus_allowed" and "Cpus_allowed_list", to provide a more intuitive and
logically grouped view for the user.

> 	- I guess this is just my poor English, but the usage of "affinity"
> 	  in the changelog/comment looks a bit confusing to me ;) As if this
> 	  refers to task_struct.cpus_mask.
> 
> 	  Fortunately "Cpus_active_mm..." in task_cpus_active_mm() makes it
> 	  more clear, so feel free to ignore.

I appreciate your perspective on the use of the word "affinity."
My intention was to describe the relationship between CPUs where a memory
descriptor is "active" and the CPUs where the thread is allowed to execute.
In other words: the affinity set the boundary; the mm_cpumask recorded the
arrival. However, I see how this could be misconstrued. I will certainly
refine the language in the changelog and ensure there is no ambiguity
between the two.


Kind regards,
-- 
Aaron Tomlin

Attachment: signature.asc
Description: PGP signature