Re: [PATCH v2] xen: xenbus: Remove create_workqueue

Re: [PATCH v2] xen: xenbus: Remove create_workqueue

[Tejun Heo]

On Tue, May 31, 2016 at 10:26:30PM +0530, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
> use of system_wq.
> 
> Unlike a dedicated per-cpu workqueue created with create_workqueue(),
> system_wq allows multiple work items to overlap executions even on
> the same CPU; however, a per-cpu workqueue doesn't have any CPU
> locality or global ordering guarantees unless the target CPU is
> explicitly specified and the increase of local concurrency shouldn't
> make any difference.
> 
> In this case, there is only a single work item, increase of concurrency
> level by switching to system_wq should not make any difference.
> 
> Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>

Acked-by: Tejun Heo <tj@kernel.org>

Thanks.

-- 
tejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] xen: xenbus: Remove create_workqueue

[Bhaktipriya Shridhar]

Ping!
Thanks,
Bhaktipriya


On Tue, May 31, 2016 at 10:59 PM, Tejun Heo <tj@kernel.org> wrote:
> On Tue, May 31, 2016 at 10:26:30PM +0530, Bhaktipriya Shridhar wrote:
>> System workqueues have been able to handle high level of concurrency
>> for a long time now and there's no reason to use dedicated workqueues
>> just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
>> use of system_wq.
>>
>> Unlike a dedicated per-cpu workqueue created with create_workqueue(),
>> system_wq allows multiple work items to overlap executions even on
>> the same CPU; however, a per-cpu workqueue doesn't have any CPU
>> locality or global ordering guarantees unless the target CPU is
>> explicitly specified and the increase of local concurrency shouldn't
>> make any difference.
>>
>> In this case, there is only a single work item, increase of concurrency
>> level by switching to system_wq should not make any difference.
>>
>> Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> Thanks.
>
> --
> tejun

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [PATCH v2] xen: xenbus: Remove create_workqueue

[David Vrabel]

On 31/05/16 17:56, Bhaktipriya Shridhar wrote:
> System workqueues have been able to handle high level of concurrency
> for a long time now and there's no reason to use dedicated workqueues
> just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
> use of system_wq.
> 
> Unlike a dedicated per-cpu workqueue created with create_workqueue(),
> system_wq allows multiple work items to overlap executions even on
> the same CPU; however, a per-cpu workqueue doesn't have any CPU
> locality or global ordering guarantees unless the target CPU is
> explicitly specified and the increase of local concurrency shouldn't
> make any difference.
> 
> In this case, there is only a single work item, increase of concurrency
> level by switching to system_wq should not make any difference.

Applied to for-linus-4.8, thanks.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[PATCH v2] xen: xenbus: Remove create_workqueue

[Bhaktipriya Shridhar]

System workqueues have been able to handle high level of concurrency
for a long time now and there's no reason to use dedicated workqueues
just to gain concurrency.  Replace dedicated xenbus_frontend_wq with the
use of system_wq.

Unlike a dedicated per-cpu workqueue created with create_workqueue(),
system_wq allows multiple work items to overlap executions even on
the same CPU; however, a per-cpu workqueue doesn't have any CPU
locality or global ordering guarantees unless the target CPU is
explicitly specified and the increase of local concurrency shouldn't
make any difference.

In this case, there is only a single work item, increase of concurrency
level by switching to system_wq should not make any difference.

Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
---
 drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +--------------
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index bcb53bd..611a231 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -31,7 +31,6 @@
 #include "xenbus_probe.h"


-static struct workqueue_struct *xenbus_frontend_wq;

 /* device/<type>/<id> => <type>-<id> */
 static int frontend_bus_id(char bus_id[XEN_BUS_ID_SIZE], const char *nodename)
@@ -109,13 +108,7 @@ static int xenbus_frontend_dev_resume(struct device *dev)
 	if (xen_store_domain_type == XS_LOCAL) {
 		struct xenbus_device *xdev = to_xenbus_device(dev);

-		if (!xenbus_frontend_wq) {
-			pr_err("%s: no workqueue to process delayed resume\n",
-			       xdev->nodename);
-			return -EFAULT;
-		}
-
-		queue_work(xenbus_frontend_wq, &xdev->work);
+		schedule_work(&xdev->work);

 		return 0;
 	}
@@ -485,12 +478,6 @@ static int __init xenbus_probe_frontend_init(void)

 	register_xenstore_notifier(&xenstore_notifier);

-	if (xen_store_domain_type == XS_LOCAL) {
-		xenbus_frontend_wq = create_workqueue("xenbus_frontend");
-		if (!xenbus_frontend_wq)
-			pr_warn("create xenbus frontend workqueue failed, S3 resume is likely to fail\n");
-	}
-
 	return 0;
 }
 subsys_initcall(xenbus_probe_frontend_init);
--
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel