fs/afs/vlocation: Remove deprecated create_singlethread_workqueue

The workqueue "afs_vlocation_update_worker" queues a single work item &afs_vlocation_update and hence it doesn't require execution ordering. Hence, alloc_workqueue has been used to replace the deprecated create_singlethread_workqueue instance.

Since the workqueue is being used on a memory reclaim path, WQ_MEM_RECLAIM flag has been set to ensure forward progress under memory pressure.

Since there are fixed number of work items, explicit concurrency limit is unnecessary here.

---
Changes in v2:
-No change.

 fs/afs/vlocation.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 5297678..45a8639 100644
@@ -594,8 +594,8 @@ static void afs_vlocation_reaper(struct work_struct *work)
  */
 int __init afs_vlocation_update_init(void)
 {
-	afs_vlocation_update_worker =
-		create_singlethread_workqueue("kafs_vlupdated");
+	afs_vlocation_update_worker = alloc_workqueue("kafs_vlupdated",
+						      WQ_MEM_RECLAIM, 0);
 	return afs_vlocation_update_worker ? 0 : -ENOMEM;
 }
 

--
2.1.4

The workqueue "afs_async_calls" queues a single work item viz &call->async_work and hence it doesn't require execution ordering. Hence, alloc_workqueue has been used to replace the deprecated create_singlethread_workqueue instance.

The WQ_MEM_RECLAIM flag has been set to ensure forward progress under memory pressure because the workqueue is being used on a memory reclaim path.

Since there are fixed number of work items, explicit concurrency limit is unnecessary here.

---
Changes in v2:
-No change

 fs/afs/rxrpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 63cd9f9..4f9e9b3 100644
@@ -85,7 +85,7 @@ int afs_open_socket(void)
 
 	skb_queue_head_init(&afs_incoming_calls);
 
-	afs_async_calls = create_singlethread_workqueue("kafsd");
+	afs_async_calls = alloc_workqueue("kafsd", WQ_MEM_RECLAIM, 0);
 	if (!afs_async_calls) {
 		_leave(" = -ENOMEM [wq]");
 		return -ENOMEM;

--
2.1.4

The workqueue "afs_callback_update_worker" queues multiple work items viz &vnode->cb_broken_work, &server->cb_break_work which require strict execution ordering. Hence, an ordered dedicated workqueue has been used.

Since the workqueue is being used on a memory reclaim path, WQ_MEM_RECLAIM has been set to ensure forward progress under memory pressure.

---
Changes in v2:
-No change

 fs/afs/callback.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index 7ef637d..1e9d2f8 100644
@@ -461,8 +461,8 @@ static void afs_callback_updater(struct work_struct *work)
  */
 int __init afs_callback_update_init(void)
 {
-	afs_callback_update_worker =
-		create_singlethread_workqueue("kafs_callbackd");
+	afs_callback_update_worker = alloc_ordered_workqueue("kafs_callbackd",
+							     WQ_MEM_RECLAIM);
 	return afs_callback_update_worker ? 0 : -ENOMEM;
 }
 

--
2.1.4

The workqueue "afs_lock_manager" queues a single work item &vnode->lock_work, and hence it doesn't require execution ordering. Hence, alloc_workqueue has been used to replace the deprecated create_singlethread_workqueue instance.

The WQ_MEM_RECLAIM flag has been set to ensure forward progress under memory pressure because the workqueue is being used on a memory reclaim path.

Since there are fixed number of work items, explicit concurrency limit is unnecessary here.

---
Changes in v2:
-No Change

 fs/afs/flock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

index d91a9c9..3191dff 100644
@@ -36,8 +36,8 @@ static int afs_init_lock_manager(void)
 	if (!afs_lock_manager) {
 		mutex_lock(&afs_lock_manager_mutex);
 		if (!afs_lock_manager) {
-			afs_lock_manager =
-				create_singlethread_workqueue("kafs_lockd");
+			afs_lock_manager = alloc_workqueue("kafs_lockd",
+							   WQ_MEM_RECLAIM, 0);
 			if (!afs_lock_manager)
 				ret = -ENOMEM;
 		}

--
2.1.4

There can be more than one single call and there's no fixed number.

There may be more than one single vnode and there's no fixed number.

David

Ah, okay, the work items are dynamically allocated. Do they need strict execution ordering or can they be executed concurrently?

Thanks.

tejun

Concurrently is fine.

David

Hello, David.

I see. Bhaktpriya, can you please update the patch description? The code itself should be fine, I think.

Thanks for the clarification.

tejun

Sure. Will update it in v2.

Thanks,
Bhaktipriya