Message ID | 20160607200853.GA13742@Karyakshetra (mailing list archive) |
---|---|
State | Accepted |
Commit | 452fa86e98061ebd528dd79e22befd5f87c83269 |
Delegated to: | Kalle Valo |
Headers | show |
On Wed, Jun 08, 2016 at 01:38:53AM +0530, Bhaktipriya Shridhar wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > A dedicated workqueue has been used since the workitem (viz > &priv->cmd_work per priv, which maps to lbtf_cmd_work) is involved in > actual command processing and may be used on a memory reclaim path. > The workitems require forward progress under memory pressure and hence, > WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work > items, explicit concurrency limit is unnecessary here. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Thanks.
Ping! Thanks, Bhaktipriya On Sun, Jun 12, 2016 at 4:17 AM, Tejun Heo <tj@kernel.org> wrote: > On Wed, Jun 08, 2016 at 01:38:53AM +0530, Bhaktipriya Shridhar wrote: >> alloc_workqueue replaces deprecated create_workqueue(). >> >> A dedicated workqueue has been used since the workitem (viz >> &priv->cmd_work per priv, which maps to lbtf_cmd_work) is involved in >> actual command processing and may be used on a memory reclaim path. >> The workitems require forward progress under memory pressure and hence, >> WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work >> items, explicit concurrency limit is unnecessary here. >> >> Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> > > Acked-by: Tejun Heo <tj@kernel.org> > > Thanks. > > -- > tejun -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> writes:
> Ping!
I'm lagging behind, the patch is still on my queue:
https://patchwork.kernel.org/patch/9162447/
Please don't top most, it's annoying.
Bhaktipriya Shridhar <bhaktipriya96@gmail.com> wrote: > alloc_workqueue replaces deprecated create_workqueue(). > > A dedicated workqueue has been used since the workitem (viz > &priv->cmd_work per priv, which maps to lbtf_cmd_work) is involved in > actual command processing and may be used on a memory reclaim path. > The workitems require forward progress under memory pressure and hence, > WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work > items, explicit concurrency limit is unnecessary here. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> > Acked-by: Tejun Heo <tj@kernel.org> Thanks, 1 patch applied to wireless-drivers-next.git: 452fa86e9806 libertas_tf: Remove create_workqueue
diff --git a/drivers/net/wireless/marvell/libertas_tf/main.c b/drivers/net/wireless/marvell/libertas_tf/main.c index 0bf8916..81463f7 100644 --- a/drivers/net/wireless/marvell/libertas_tf/main.c +++ b/drivers/net/wireless/marvell/libertas_tf/main.c @@ -742,7 +742,7 @@ EXPORT_SYMBOL_GPL(lbtf_bcn_sent); static int __init lbtf_init_module(void) { lbtf_deb_enter(LBTF_DEB_MAIN); - lbtf_wq = create_workqueue("libertastf"); + lbtf_wq = alloc_workqueue("libertastf", WQ_MEM_RECLAIM, 0); if (lbtf_wq == NULL) { printk(KERN_ERR "libertastf: couldn't create workqueue\n"); return -ENOMEM;
alloc_workqueue replaces deprecated create_workqueue(). A dedicated workqueue has been used since the workitem (viz &priv->cmd_work per priv, which maps to lbtf_cmd_work) is involved in actual command processing and may be used on a memory reclaim path. The workitems require forward progress under memory pressure and hence, WQ_MEM_RECLAIM has been set. Since there are only a fixed number of work items, explicit concurrency limit is unnecessary here. Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> --- drivers/net/wireless/marvell/libertas_tf/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html