From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: Tejun Heo <tj@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] workqueue: remove the unneeded cpu_relax() in __queue_work()
Date: Mon, 26 May 2014 11:19:05 +0800 [thread overview]
Message-ID: <5382B2A9.7030906@cn.fujitsu.com> (raw)
In-Reply-To: <CACvQF53Xs91KMdsYCsqM-NNJYtb+byajjc668aiM2vMFBv3JaA@mail.gmail.com>
On 05/22/2014 10:21 PM, Lai Jiangshan wrote:
> On Thu, May 22, 2014 at 9:47 PM, Tejun Heo <tj@kernel.org> wrote:
>> On Thu, May 22, 2014 at 04:44:16PM +0800, Lai Jiangshan wrote:
>>> When pwq->refcnt == 0, the retrying is guaranteed to make forward-progress.
>>> The comment above the code explains it well:
>>>
>>> /*
>>> * pwq is determined and locked. For unbound pools, we could have
>>> * raced with pwq release and it could already be dead. If its
>>> * refcnt is zero, repeat pwq selection. Note that pwqs never die
>>> * without another pwq replacing it in the numa_pwq_tbl or while
>>> * work items are executing on it, so the retrying is guaranteed to
>>> * make forward-progress.
>>> */
>>>
>>> It means the cpu_relax() here is useless and sometimes misleading,
>>> it should retry directly and make some progress rather than waste time.
>>
>> cpu_relax() doesn't have much to do with guaranteeing forward
>> progress. It's about giving a breather during busy wait so that the
>
> 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,
> 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.
>
> Thanks,
> Lai
Ping.
Any comments?
>
>> waiting cpu doesn't busy loop claiming the same cache lines over and
>> over ultimately delaying the event being waited on. If you're doing a
>> busy wait, you better use cpu_relax().
>>
>> Thanks.
>>
>> --
>> tejun
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2014-05-26 3:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 8:44 [PATCH] workqueue: remove the unneeded cpu_relax() in __queue_work() Lai Jiangshan
2014-05-22 13:47 ` Tejun Heo
2014-05-22 14:21 ` Lai Jiangshan
2014-05-26 3:19 ` Lai Jiangshan [this message]
2014-05-26 4:23 ` Tejun Heo
2014-05-26 5:27 ` Lai Jiangshan
2014-05-26 10:54 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5382B2A9.7030906@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.