linux-kernel - Re: [PATCH] workqueue: remove the unneeded cpu_relax() in __queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140522134758.GA5065@htj.dyndns.org>
Date:	Thu, 22 May 2014 09:47:58 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Lai Jiangshan <laijs@...fujitsu.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: remove the unneeded cpu_relax() in
 __queue_work()

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
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/