linux-kernel - Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 8 Sep 2010 18:28:19 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org, xfs@....sgi.com,
	linux-fsdevel@...r.kernel.org
Subject: Re: [2.6.36-rc3] Workqueues, XFS, dependencies and deadlocks

On Wed, Sep 08, 2010 at 10:20:27AM +0200, Tejun Heo wrote:
> On 09/08/2010 09:34 AM, Dave Chinner wrote:
> >> Probably I have overloaded the term 'concurrency' too much.  In this
> >> case, I meant the number of workers assigned to work items of the wq.
> >> If you fire off N work items which sleep at the same time, cmwq will
> >> eventually try to create N workers as each previous worker goes to
> >> sleep so that the CPU doesn't sit idle while there are work items to
> >> process as long as N < @wq->nr->active.
> > 
> > Ok, so if I queue N items on a single CPU when max_active == N, they
> > get spread across N worker threads on different CPUs? 
> 
> They may if necessary to keep the workqueue progressing.

Ok, so the normal case is that they will all be processed local to the
CPU they were queued on, like the old workqueue code?

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/