Why task scheduler threads are waiting during rendering?

[mrc3...@gmail.com]

Hi everybody

When I look at the threads of task scheduler, I see that they are waiting for work most of times while the rendere thread as well as compositor are working (Screenshots are attached). Can you explain what does it mean?

Thanks,

[François Doray]

When a TaskScheduler worker is waiting in SchedulerWorker::Delegate::WaitForWork, it normally means that no task is waiting to be executed in TaskScheduler. The worker is not consuming any CPU when waiting in SchedulerWorker::Delegate::WaitForWork.

The fact that the main thread and the compositor thread are busy while TaskScheduler workers are idle means that the work being done on the main thread and the compositor thread has not been written for concurrent execution. It might be interesting to investigate changing the code to allow concurrent execution, but that will not necessarily make it faster and is not necessarily compatible with the single-threaded execution model of the Web.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/f65db0a1-6229-4401-b520-9be840db4a16%40chromium.org.

[mrc3...@gmail.com]

Thanks for your response Francois

Based on what you said, does it mean that rendering a web page is almost sequential not parallel?

Can we say that the critical path of rendering a page is inside CrRendereMain and compositor threads? In other words, can we say that these two threads are executing the tasks in a loop and consequently, we can look at them if we want to find the critical path of execution?

[dan...@chromium.org]

On Tue, Sep 18, 2018 at 6:40 PM <mrc3...@gmail.com> wrote:

Thanks for your response Francois

Based on what you said, does it mean that rendering a web page is almost sequential not parallel?

Can we say that the critical path of rendering a page is inside CrRendereMain and compositor threads? In other words, can we say that these two threads are executing the tasks in a loop and consequently, we can look at them if we want to find the critical path of execution?

Not entirely, rasterization happens in a worker thread pool, with more parallelism, and is part of the critical path too. The compositor and main threads in the GPU process, and the UI thread in the browser, are part of the critical path, though these are not parallel to the renderer's work for a single frame. We use pipelining (preparing frames ahead of time) to get more throughput in the system since the critical path has limited parallelism.

 

On Tuesday, September 18, 2018 at 5:38:25 PM UTC-4, François wrote:

When a TaskScheduler worker is waiting in SchedulerWorker::Delegate::WaitForWork, it normally means that no task is waiting to be executed in TaskScheduler. The worker is not consuming any CPU when waiting in SchedulerWorker::Delegate::WaitForWork.

The fact that the main thread and the compositor thread are busy while TaskScheduler workers are idle means that the work being done on the main thread and the compositor thread has not been written for concurrent execution. It might be interesting to investigate changing the code to allow concurrent execution, but that will not necessarily make it faster and is not necessarily compatible with the single-threaded execution model of the Web.

On Tue, Sep 18, 2018 at 5:25 PM <mrc3...@gmail.com> wrote:

Hi everybody

When I look at the threads of task scheduler, I see that they are waiting for work most of times while the rendere thread as well as compositor are working (Screenshots are attached). Can you explain what does it mean?

Thanks,

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/f65db0a1-6229-4401-b520-9be840db4a16%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/7d6ccc63-d3b5-470a-a752-a12197f60104%40chromium.org.

[mrc3...@gmail.com]

Thanks for your response. Although the threads you mentioned can be involved in critical path generally, we can perceive that most time-consuming tasks are being running in CrRendereMain. So, can we say that most likely the critical path of loading a web page will be placed in CrRendereMain? When it comes to critical path, I mean the path which suffers from the longest latency while the other tasks are running in parallel, is it correct?