On Thu 04-02-16 07:37:23, Michal Hocko wrote: > On Wed 03-02-16 11:59:01, Tejun Heo wrote: > > On Wed, Feb 03, 2016 at 05:48:52PM +0100, Michal Hocko wrote: > [...] > > > anything and add_timer_on also for WORK_CPU_UNBOUND is really required > > > then we should at least preserve WORK_CPU_UNBOUND in dwork->cpu so that > > > __queue_work can actually move on to the local CPU properly and handle > > > the offline cpu properly. > > > > delayed_work->cpu is determined on queueing time. Dealing with > > offlined cpus at execution is completley fine. There's no need to > > "preserve" anything. > > I've seen you have posted a fix in the mean time but just for my > understading. Why the following is not an appropriate fix? > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > index c579dbab2e36..52bb11cf20d1 100644 > --- a/kernel/workqueue.c > +++ b/kernel/workqueue.c > @@ -1459,9 +1459,9 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq, > > dwork->wq = wq; > /* timer isn't guaranteed to run in this cpu, record earlier */ > + dwork->cpu = cpu; > if (cpu == WORK_CPU_UNBOUND) > cpu = raw_smp_processor_id(); > - dwork->cpu = cpu; > timer->expires = jiffies + delay; > > add_timer_on(timer, cpu); Ok, so after some more thinking about that, this won't really help for memory less CPU which would still have NUMA_NO_NODE associated with it AFAIU. So this is definitely better to be handled at unbound_pwq_by_node level. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html