Run task queue manager work in batches

content/renderer/scheduler/task_queue_manager.cc

Index: content/renderer/scheduler/task_queue_manager.cc
diff --git a/content/renderer/scheduler/task_queue_manager.cc b/content/renderer/scheduler/task_queue_manager.cc
index eed64494175b782cb816212a84c357f50fcae7e9..515264bac2ad8f32adfedd7a4aeb308e78f74329 100644
--- a/content/renderer/scheduler/task_queue_manager.cc
+++ b/content/renderer/scheduler/task_queue_manager.cc
@@ -245,6 +245,7 @@ TaskQueueManager::TaskQueueManager(
     : main_task_runner_(main_task_runner),
       selector_(selector),
       pending_dowork_count_(0),
+      work_batch_size_(1),
       weak_factory_(this) {
   DCHECK(main_task_runner->RunsTasksOnCurrentThread());
   TRACE_EVENT_OBJECT_CREATED_WITH_ID(
@@ -332,14 +333,18 @@ void TaskQueueManager::DoWork(bool posted_from_main_thread) {
     DCHECK_GE(pending_dowork_count_, 0);
   }
   main_thread_checker_.CalledOnValidThread();
-  if (!UpdateWorkQueues())
-    return;
 
-  size_t queue_index;
-  if (!SelectWorkQueueToService(&queue_index))
-    return;
-  MaybePostDoWorkOnMainRunner();
-  ProcessTaskFromWorkQueue(queue_index);
+  for (int i = 0; i < work_batch_size_; i++) {
+    if (!UpdateWorkQueues())
+      return;
+
+    size_t queue_index;
+    if (!SelectWorkQueueToService(&queue_index))
+      return;
+    if (i == 0)
+      MaybePostDoWorkOnMainRunner();
+    ProcessTaskFromWorkQueue(queue_index);
+  }

[rmcilroy, 2015/01/14 17:56:37]

Would the following work:

if (!UpdateWorkQueues())
  return;
MaybePostDoWorkOnMainRunner();

for (int i = 0; i < work_batch_size_; i++) {
  if (!SelectWorkQueueToService(&queue_index))
     return;
  ProcessTaskFromWorkQueue(queue_index);
}

It's a bit simpler, and ensures that we only take the locks in UpdateWorkQueues
once per batch, but does mean that that a given batch won't include any work
posted from any DoWorks for that batch. Would this prevent any batching being
possible on the indexdb perf test?

[Sami, 2015/01/14 18:11:49]

I had the same idea and chose to do polling inside the batch to minimize the
chances that we yield and then immediately come back since there was more work.
The idea was simply that it's more likely there's more work waiting for us
inside the task queue manager than outside of it. I can definitely see the point
about taking fewer locks if there really isn't anything to do. 

Let me check how this fares with the indexeddb benchmark.

On 2015/01/14 17:56:37, rmcilroy wrote:
I don't think we can do this here because the selector should be able to prevent
any DoWorks from getting posted if it wants.
Here we need to check if any of the queues became empty and bail out.

[rmcilroy, 2015/01/14 19:34:48]

Good point
Ack
Ahh that's sad, but having thought about it a bit more it probably wouldn't be a
great plan anyway because without updating the work queues every cycle the
selector wouldn't necessarily make the correct decision.

 }
 
 bool TaskQueueManager::SelectWorkQueueToService(size_t* out_queue_index) {
@@ -388,6 +393,12 @@ void TaskQueueManager::SetQueueName(size_t queue_index, const char* name) {
   queue->set_name(name);
 }
 
+void TaskQueueManager::SetWorkBatchSize(int work_batch_size) {
+  main_thread_checker_.CalledOnValidThread();
+  DCHECK_GE(work_batch_size, 1);
+  work_batch_size_ = work_batch_size;
+}
+
 scoped_refptr<base::debug::ConvertableToTraceFormat>
 TaskQueueManager::AsValueWithSelectorResult(bool should_run,
                                             size_t selected_queue) const {