Skip to contentSkip to conversation

s390: Remove deprecated create_singlethread_workqueue

PATCH In review Bhaktipriya Shridhar 3 participants 3 messages Aug 30, 2016 – Sep 3, 2016

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 s390: Remove deprecated create_singlethread_workqueue

The workqueue "appldata_wq" has been replaced with an ordered dedicated workqueue.

WQ_MEM_RECLAIM has not been set since the workqueue is not being used on a memory reclaim path.

The adapter->work_queue queues multiple work items viz &adapter->scan_work, &port->rport_work, &adapter->ns_up_work, &adapter->stat_work, adapter->work_queue, &adapter->events.work, &port->gid_pn_work, &port->test_link_work. Hence, an ordered dedicated workqueue has been used.

WQ_MEM_RECLAIM has been set to ensure forward progress under memory pressure.

---
 arch/s390/appldata/appldata_base.c | 2 +-
 drivers/s390/scsi/zfcp_aux.c       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
arch/s390/appldata/appldata_base.c +1 -1
index 15c9424..f587c48 100644
@@ -542,7 +542,7 @@ static int __init appldata_init(void)
 		rc = PTR_ERR(appldata_pdev);
 		goto out_driver;
 	}
-	appldata_wq = create_singlethread_workqueue("appldata");
+	appldata_wq = alloc_ordered_workqueue("appldata", 0);
 	if (!appldata_wq) {
 		rc = -ENOMEM;
 		goto out_device;
drivers/s390/scsi/zfcp_aux.c +1 -1
index c00ac46..bcc8f3d 100644
@@ -310,7 +310,7 @@ static int zfcp_setup_adapter_work_queue(struct zfcp_adapter *adapter)
 
 	snprintf(name, sizeof(name), "zfcp_q_%s",
 		 dev_name(&adapter->ccw_device->dev));
-	adapter->work_queue = create_singlethread_workqueue(name);
+	adapter->work_queue = alloc_ordered_workqueue(name, WQ_MEM_RECLAIM);
 
 	if (adapter->work_queue)
 		return 0;

--
2.1.4

#1 lore raw
Quoted 6 lines · Bhaktipriya Shridhar

The workqueue "appldata_wq" has been replaced with an ordered dedicated workqueue.

WQ_MEM_RECLAIM has not been set since the workqueue is not being used on a memory reclaim path.

Quoted 8 lines

The adapter->work_queue queues multiple work items viz &adapter->scan_work, &port->rport_work, &adapter->ns_up_work, &adapter->stat_work, adapter->work_queue, &adapter->events.work, &port->gid_pn_work, &port->test_link_work. Hence, an ordered dedicated workqueue has been used.

WQ_MEM_RECLAIM has been set to ensure forward progress under memory pressure.

I have no idea what these drivers do. s390 folks, can you please shed some light on whether these workqueues can be depended on during memory reclaim?

Thanks.

Signature · 1 line
tejun
#2 lore raw
Quoted 13 lines · Tejun Heo
Quoted 12 lines · Bhaktipriya Shridhar

The workqueue "appldata_wq" has been replaced with an ordered dedicated workqueue.

WQ_MEM_RECLAIM has not been set since the workqueue is not being used on a memory reclaim path.

The adapter->work_queue queues multiple work items viz &adapter->scan_work, &port->rport_work, &adapter->ns_up_work, &adapter->stat_work, adapter->work_queue, &adapter->events.work, &port->gid_pn_work, &port->test_link_work. Hence, an ordered dedicated workqueue has been used.

Quoted 6 lines
Quoted 2 lines

WQ_MEM_RECLAIM has been set to ensure forward progress under memory pressure.

I have no idea what these drivers do. s390 folks, can you please shed some light on whether these workqueues can be depended on during memory reclaim?

The appldata device driver is only needed to gather statistical data and therefore my wait when memory reclaim is in progress.

The zfcp device drivers is a SCSI-over-FC device driver and hence we depend on it during memory reclaim. So setting WQ_MEM_RECLAIM is the right thing to do here.

The patch looks ok, and I applied it.

Thanks!