* [PATCH] Drivers: hv: connection: Remove create_workqueue
@ 2016-06-18 8:44 Bhaktipriya Shridhar
2016-06-20 15:09 ` Tejun Heo
0 siblings, 1 reply; 2+ messages in thread
From: Bhaktipriya Shridhar @ 2016-06-18 8:44 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang; +Cc: Tejun Heo, devel, linux-kernel
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
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] Drivers: hv: connection: Remove create_workqueue
2016-06-18 8:44 [PATCH] Drivers: hv: connection: Remove create_workqueue Bhaktipriya Shridhar
@ 2016-06-20 15:09 ` Tejun Heo
0 siblings, 0 replies; 2+ messages in thread
From: Tejun Heo @ 2016-06-20 15:09 UTC (permalink / raw)
To: Bhaktipriya Shridhar; +Cc: K. Y. Srinivasan, Haiyang Zhang, devel, linux-kernel
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-06-20 15:10 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-18 8:44 [PATCH] Drivers: hv: connection: Remove create_workqueue Bhaktipriya Shridhar
2016-06-20 15:09 ` Tejun Heo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).