On 8/5/24 18:23, Frederic Weisbecker wrote: > Le Mon, Aug 05, 2024 at 04:53:51PM +0200, Vlastimil Babka a écrit : >> If you mean the loop in kcompactd_init() then indeed, but we also have a >> hook in online_pages() to start new threads on newly onlined nodes, so >> that's not a problem. >> >> The problem (I think) I see is cpumask_of_node(pgdat->node_id) is a snapshot >> of cpus running on the NUMA node the time, and is never updated later as new >> cpus might be brought up. > > Oh I see now... > >> >> kcompactd_cpu_online() does try to update that when cpus are onlined (in a >> clumsy way), there was nothing like that for kswapd and after your series >> this update is also removed for kcompactd. > > Ok... > >> >> > If all users of preferred affinity were to use NUMA nodes, it could be >> > a good idea to do a flavour of kernel/smpboot.c which would handle >> > per-node kthreads instead of per-cpu kthreads. I initially thought >> > about that. It would have handled all the lifecycle of those kthreads, >> > including creation, against hotplug. Unfortunately RCU doesn't rely on >> > per-NUMA nodes but rather use its own tree. >> > >> > If there be more users of real per NUMA nodes kthreads than kswapd and >> > kcompactd, of course that would be much worth considering. >> >> Yeah it's not that compelling, but a way to update the preferred affine mask >> in response to cpu hotplug events, that kswapd and kcompactd could use, >> would be sufficient. And maybe more widely useful. >> >> I guess there could be a callback defined for kthread to provide a new >> preferred_affinity, that you'd call from kthreads_hotplug_update() ? >> And kcompactd and kswapd could both use the same callback that interprets >> kthread_data() as pgdat and fetches a new cpumask of it? > > It's too bad we don't have a way to have a cpumask_possible_of_node(). I've > looked into the guts of numa but that doesn't look easy to do. That was my impression as well. Maybe not even possible because exact cpu ids might not be pre-determined like this? > Or there could be kthread_set_preferred_node()... ? Possible instead of the callback idea suggested above? kthreads_hotplug_update() could check if this is set and construct the mask accordingly. > Thanks. > >> >> > Thanks. >>
