[PATCH 1/3] arch: Introduce ARCH_HAS_CPUMASK_BITS
David Hildenbrand
david at redhat.com
Tue Apr 4 23:47:56 AEST 2023
On 04.04.23 15:42, Yair Podemsky wrote:
> Some architectures set and maintain the mm_cpumask bits when loading
> or removing process from cpu.
> This Kconfig will mark those to allow different behavior between
> kernels that maintain the mm_cpumask and those that do not.
>
I was wondering if we should do something along the lines of:
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 0722859c3647..1f5c15d8e8ed 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -767,11 +767,13 @@ struct mm_struct {
#endif /* CONFIG_LRU_GEN */
} __randomize_layout;
+#ifdef CONFIG_MM_CPUMASK
/*
* The mm_cpumask needs to be at the end of mm_struct, because it
* is dynamically sized based on nr_cpu_ids.
*/
unsigned long cpu_bitmap[];
+#endif
};
But that would, of course, require additional changes to make it
compile. What concerns me a bit is that we have in mm/rmap.c a
mm_cpumask() usage. But it's glued to
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH ... shaky.
At least if we would properly fence it, there would be no
accidental abuse anymore.
> Signed-off-by: Yair Podemsky <ypodemsk at redhat.com>
> ---
> arch/Kconfig | 8 ++++++++
> arch/arm/Kconfig | 1 +
> arch/powerpc/Kconfig | 1 +
> arch/s390/Kconfig | 1 +
> arch/sparc/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
As Valentin says, there are other architectures that do the same.
--
Thanks,
David / dhildenb
More information about the Linuxppc-dev
mailing list