>> And, do u mean @cpu is WORK_CPU_UNBOUND? > > @cpu could be WORK_CPU_UNBOUND at that point. The timer will be added > to local CPU but @work->data would be pointing to WORK_CPU_UNBOUND, > again triggering the condition. Given that @cpu being > WORK_CPU_UNBOUND is far more common than an actual CPU number, the > patch would actually increase spurious nrt lookups. The right thing > to do is probably setting cpu to raw_smp_processor_id() beforehand.
I got your point. Thanks for kind illustration. Following is a alternative implementation for this. I thinks this is too rare case, so it doesn't help in any real workload. But how do you thinks? @@ -1156,7 +1156,9 @@ int queue_delayed_work_on(int cpu, struct workqueue_struct *wq, if (!(wq->flags & WQ_UNBOUND)) { struct global_cwq *gcwq = get_work_gcwq(work); - if (gcwq && gcwq->cpu != WORK_CPU_UNBOUND) + if (!gcwq) + lcpu = cpu; + else if (gcwq->cpu != WORK_CPU_UNBOUND) lcpu = gcwq->cpu; else lcpu = raw_smp_processor_id(); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/