Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1461655 > unrolled thread
| Started by | Bhaktipriya Shridhar <bhaktipriya96@gmail.com> |
|---|---|
| First post | 2016-08-13 18:50 +0200 |
| Last post | 2016-08-16 01:10 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH] android: binder: Remove deprecated create_singlethread_workqueue Bhaktipriya Shridhar <bhaktipriya96@gmail.com> - 2016-08-13 18:50 +0200
Re: [PATCH] android: binder: Remove deprecated create_singlethread_workqueue Tejun Heo <tj@kernel.org> - 2016-08-16 01:10 +0200
| From | Bhaktipriya Shridhar <bhaktipriya96@gmail.com> |
|---|---|
| Date | 2016-08-13 18:50 +0200 |
| Subject | [PATCH] android: binder: Remove deprecated create_singlethread_workqueue |
| Message-ID | <s5Kid-3N8-11@gated-at.bofh.it> |
The workqueue is being used to run deferred work for the android binder.
The "binder_deferred_workqueue" queues only a single work item and hence
does not require ordering. Also, this workqueue is not being used on a
memory recliam path. Hence, the singlethreaded workqueue has been
replaced with the use of system_wq.
System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_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
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com>
---
drivers/android/binder.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 16288e7..562af94 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -59,7 +59,6 @@ static struct dentry *binder_debugfs_dir_entry_proc;
static struct binder_node *binder_context_mgr_node;
static kuid_t binder_context_mgr_uid = INVALID_UID;
static int binder_last_id;
-static struct workqueue_struct *binder_deferred_workqueue;
#define BINDER_DEBUG_ENTRY(name) \
static int binder_##name##_open(struct inode *inode, struct file *file) \
@@ -3227,7 +3226,7 @@ binder_defer_work(struct binder_proc *proc, enum binder_deferred_state defer)
if (hlist_unhashed(&proc->deferred_work_node)) {
hlist_add_head(&proc->deferred_work_node,
&binder_deferred_list);
- queue_work(binder_deferred_workqueue, &binder_deferred_work);
+ schedule_work(&binder_deferred_work);
}
mutex_unlock(&binder_deferred_lock);
}
@@ -3679,10 +3678,6 @@ static int __init binder_init(void)
{
int ret;
- binder_deferred_workqueue = create_singlethread_workqueue("binder");
- if (!binder_deferred_workqueue)
- return -ENOMEM;
-
binder_debugfs_dir_entry_root = debugfs_create_dir("binder", NULL);
if (binder_debugfs_dir_entry_root)
binder_debugfs_dir_entry_proc = debugfs_create_dir("proc",
--
2.1.4
[toc] | [next] | [standalone]
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2016-08-16 01:10 +0200 |
| Message-ID | <s6zb3-3AC-5@gated-at.bofh.it> |
| In reply to | #1461655 |
On Sat, Aug 13, 2016 at 10:16:24PM +0530, Bhaktipriya Shridhar wrote: > The workqueue is being used to run deferred work for the android binder. > > The "binder_deferred_workqueue" queues only a single work item and hence > does not require ordering. Also, this workqueue is not being used on a > memory recliam path. Hence, the singlethreaded workqueue has been > replaced with the use of system_wq. > > System workqueues have been able to handle high level of concurrency > for a long time now and hence it's not required to have a singlethreaded > workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue > created with create_singlethread_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 > guarantee unless the target CPU is explicitly specified and thus the > increase of local concurrency shouldn't make any difference. > > Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Thanks. -- tejun
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web