| Message ID | 20240423083043.3735921-6-dawei.li@shingroup.cn |
|---|---|
| State | New |
| Headers | show |
| Series | Remove onstack cpumask var for sparc | expand |
Hi Dawei. On Tue, Apr 23, 2024 at 04:30:42PM +0800, Dawei Li wrote: > In general it's preferable to avoid placing cpumasks on the stack, as > for large values of NR_CPUS these can consume significant amounts of > stack space and make stack overflows more likely. > > Since the cpumask var resides in __init function, which means it's free > of any concurrenct access, it can be safely marked with static to get > rid of allocation on stack. > > Signed-off-by: Dawei Li <dawei.li@shingroup.cn> I am not convinced this patch is the right approach, and I am not sure it is worth trying to fix it. This patch adds complexity, where the other patches simplified code. I recommend to drop this, we can re-visit if this turns out to be a real problem. Sam
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c index 1ca9054d9b97..9edbf57a2c59 100644 --- a/arch/sparc/mm/init_64.c +++ b/arch/sparc/mm/init_64.c @@ -1438,7 +1438,7 @@ static int __init numa_attach_mlgroup(struct mdesc_handle *md, u64 grp, static int __init numa_parse_mdesc_group(struct mdesc_handle *md, u64 grp, int index) { - cpumask_t mask; + static cpumask_t mask; int cpu; numa_parse_mdesc_group_cpus(md, grp, &mask);
In general it's preferable to avoid placing cpumasks on the stack, as for large values of NR_CPUS these can consume significant amounts of stack space and make stack overflows more likely. Since the cpumask var resides in __init function, which means it's free of any concurrenct access, it can be safely marked with static to get rid of allocation on stack. Signed-off-by: Dawei Li <dawei.li@shingroup.cn> --- arch/sparc/mm/init_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)