On Mon, Sep 8, 2025 at 10:33 AM Mete Durlu <meted@xxxxxxxxxxxxx> wrote: > > If I get this correctly system_wq will be obsolete and users will get > system_percpu_wq instead, which means local cpu gets to deal with the > delayed work and its timer and it has an affinity to that cpu via per > cpu workqueue. In that case; > > > diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c > > index e7b66d046e8d..85b5508ab62c 100644 > > --- a/arch/s390/kernel/hiperdispatch.c > > +++ b/arch/s390/kernel/hiperdispatch.c > > @@ -191,7 +191,7 @@ int hd_enable_hiperdispatch(void) > > return 0; > > if (hd_online_cores <= hd_entitled_cores) > > return 0; > > - mod_delayed_work(system_wq, &hd_capacity_work, HD_DELAY_INTERVAL * hd_delay_factor); > > + mod_delayed_work(system_percpu_wq, &hd_capacity_work, HD_DELAY_INTERVAL * hd_delay_factor); > > hd_update_capacities(); > > Hiperdispatch's delayed work wouldn't get a noticeable benefit from > utilizing a per-cpu workqueue. We probably settled on system_wq to > utilize the global work queue at the time. Would system_unbound_wq > make more sense here? > > Thanks. Hello, I will check the code and if it is possible, I will send the v2 with system_dfl_wq (eg. the current/old system_unbound_wq). Thanks! -- Marco Crivellari L3 Support Engineer, Technology & Product marco.crivellari@xxxxxxxx
