Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1425676 > unrolled thread

[PATCH] Drivers: hv: connection: Remove create_workqueue

Back to article view | Back to linux.kernel

Contents

  [PATCH] Drivers: hv: connection: Remove create_workqueue Bhaktipriya Shridhar <bhaktipriya96@gmail.com> - 2016-06-18 10:50 +0200
    Re: [PATCH] Drivers: hv: connection: Remove create_workqueue Tejun Heo <tj@kernel.org> - 2016-06-20 17:20 +0200

#1425676 — [PATCH] Drivers: hv: connection: Remove create_workqueue

alloc_workqueue replaces deprecated create_workqueue().
A dedicated workqueue has been used since the workitem (viz &ctx->work,
which maps to vmbus_onmessage_work), is engaged in normal device
operation which involves invoking the handler for channel protocol
messages. WQ_MEM_RECLAIM has been set to guarantee forward progress under
memory pressure, which is a requirement in this case.
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/hv/connection.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index fcf8a02..a292b85 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -147,7 +147,8 @@ int vmbus_connect(void)

 	/* Initialize the vmbus connection */
 	vmbus_connection.conn_state = CONNECTING;
-	vmbus_connection.work_queue = create_workqueue("hv_vmbus_con");
+	vmbus_connection.work_queue = alloc_workqueue("hv_vmbus_con",
+						      WQ_MEM_RECLAIM, 0);
 	if (!vmbus_connection.work_queue) {
 		ret = -ENOMEM;
 		goto cleanup;
--
2.1.4

[toc] | [next] | [standalone]

#1426690

Hello,

On Sat, Jun 18, 2016 at 02:14:23PM +0530, Bhaktipriya Shridhar wrote:
> alloc_workqueue replaces deprecated create_workqueue().
> A dedicated workqueue has been used since the workitem (viz &ctx->work,
> which maps to vmbus_onmessage_work), is engaged in normal device
> operation which involves invoking the handler for channel protocol
> messages. WQ_MEM_RECLAIM has been set to guarantee forward progress under
> memory pressure, which is a requirement in this case.
> 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/hv/connection.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index fcf8a02..a292b85 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -147,7 +147,8 @@ int vmbus_connect(void)
> 
>  	/* Initialize the vmbus connection */
>  	vmbus_connection.conn_state = CONNECTING;
> -	vmbus_connection.work_queue = create_workqueue("hv_vmbus_con");
> +	vmbus_connection.work_queue = alloc_workqueue("hv_vmbus_con",
> +						      WQ_MEM_RECLAIM, 0);

This is part of a hypervisor, right?  I'm not sure why this would need
WQ_MEM_RECLAIM.  It doesn't play any role during memory reclaim,
right?

Thanks.

-- 
tejun

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web