On 06/20/2016 08:59 PM, Tejun Heo wrote:
On Tue, Jun 07, 2016 at 01:00:13PM -0700, Bart Van Assche wrote:
srp_remove_wq is used for SRP target port removal work only. This work is
neither queued from inside a shrinker nor by the page writeback code so I
think it is safe to drop WQ_MEM_RECLAIM.
It should be able to use system_wq then.
No. I have tried that but that resulted in a deadlock.
See also commit bcc059103591 for the details.
So, create_workqueue() limits concurrency to 1 per cpu and if you have
a dependency between two work items and they get scheduled on the same
cpu they can deadlock. system_wq doesn't have that restriction and
should be fine, AFAICS.
Agreed, as long as WQ_DFL_ACTIVE is not reduced from its current value
(256) to a very low value (e.g. 1 or 2). This assumption should be
documented but I'm not sure what the best way is to document this...
Bart.
