xen: xenbus: Remove create_workqueue
PATCH v2 1/1 xen: xenbus: Remove create_workqueue
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.
--- drivers/xen/xenbus/xenbus_probe_frontend.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-)
drivers/xen/xenbus/xenbus_probe_frontend.c +1 -14
@@ -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
Quoted 12 lines · 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_wqwith the use ofsystem_wq.Unlike a dedicated per-cpu workqueue created with
create_workqueue(),system_wqallows 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.
Quoted 4 lines
In this case, there is only a single work item, increase of concurrency level by switching to
system_wqshould not make any difference.Signed-off-by Bhaktipriya Shridhar <[email protected]>
Thanks.
Signature · 6 lines
tejun _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
Quoted 12 lines · 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_wqwith the use ofsystem_wq.Unlike a dedicated per-cpu workqueue created with
create_workqueue(),system_wqallows 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.
Quoted 4 lines
In this case, there is only a single work item, increase of concurrency level by switching to
system_wqshould not make any difference.Signed-off-by Bhaktipriya Shridhar <[email protected]>
Thanks.
Signature · 1 line
tejun
Ping!
Thanks,
Bhaktipriya
Quoted 16 lines · Tejun Heo
Quoted 15 lines · 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_wqwith the use ofsystem_wq.Unlike a dedicated per-cpu workqueue created with
create_workqueue(),system_wqallows 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_wqshould not make any difference.
Quoted 8 lines
Quoted 1 line
Signed-off-by Bhaktipriya Shridhar <[email protected]>Acked-by Tejun Heo <[email protected]>Thanks.
--
tejun
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
David Vrabel
AppliedQuoted 12 lines · 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_wqwith the use ofsystem_wq.Unlike a dedicated per-cpu workqueue created with
create_workqueue(),system_wqallows 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.
Quoted 2 lines
In this case, there is only a single work item, increase of concurrency level by switching to
system_wqshould not make any difference.
Applied to for-linus-4.8, thanks.
David
David Vrabel
AppliedQuoted 12 lines · 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_wqwith the use ofsystem_wq.Unlike a dedicated per-cpu workqueue created with
create_workqueue(),system_wqallows 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.
Quoted 2 lines
In this case, there is only a single work item, increase of concurrency level by switching to
system_wqshould not make any difference.
Applied to for-linus-4.8, thanks.
David
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel