From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753195AbcFTPKM (ORCPT ); Mon, 20 Jun 2016 11:10:12 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:34537 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751577AbcFTPKE (ORCPT ); Mon, 20 Jun 2016 11:10:04 -0400 Date: Mon, 20 Jun 2016 11:09:57 -0400 From: Tejun Heo To: Bhaktipriya Shridhar Cc: "K. Y. Srinivasan" , Haiyang Zhang , devel@linuxdriverproject.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Drivers: hv: connection: Remove create_workqueue Message-ID: <20160620150957.GX3262@mtj.duckdns.org> References: <20160618084423.GA8865@Karyakshetra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160618084423.GA8865@Karyakshetra> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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