On 05/26/2014 12:23 PM, Tejun Heo wrote: > On Thu, May 22, 2014 at 10:21:25PM +0800, Lai Jiangshan wrote: >> On Thu, May 22, 2014 at 9:47 PM, Tejun Heo <t...@kernel.org> wrote: >> This is not busy wait, the retry and numa_pwq_tbl() guarantee that >> the retry will get a new pwq (even without cpu_relax()) as the comments says, > > Yes, *eventually*. It's not guaranteed to succeed on the immediate > next try. This is a busy wait.
changing pwq: install pwq lock(pool->lock) put_pwq(); unlock(pool->lock) __queue_work(): lock(pool->lock) test ref and find it zero; see the installation here; it is guaranteed to get the installed pwq on the immediate next try. unlock() retry. > >> and the refcnt of this new pwq is very very likely non-zero and >> cpu_relax() can't >> increase the probability of non-zero-refcnt. cpu_relax() is useless here. >> >> It is different from spin_lock() or some other spin code. >> >> it is similar to the loop of __task_rq_lock() which also guarantees progress. > > No, it's not. __task_rq_lock() *already* sees the updated value to > use for the next time. Here, we see the old one dead and the new one > is guaranteed to show up pretty soon but we're still busy waiting for > it. > -- 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/