Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(22)

Issue 2414063002: TaskScheduler: Always remove SchedulerWorker from idle stack on wake up. (Closed)

Created:
4 years, 2 months ago by fdoray
Modified:
4 years, 2 months ago
Reviewers:
robliao, gab
CC:
chromium-reviews, gab+watch_chromium.org, robliao+watch_chromium.org, fdoray+watch_chromium.org
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

TaskScheduler: Always remove SchedulerWorker from idle stack on wake up. With this CL, posting a SINGLE_THREADED task removes the target SchedulerWorker from the idle stack. BUG=553459 Committed: https://crrev.com/b7bd6bb60139b16375cd666f8f4ff79e072f18a0 Cr-Commit-Position: refs/heads/master@{#425132}

Patch Set 1 #

Total comments: 2

Patch Set 2 : CR robliao #3 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+15 lines, -2 lines) Patch
M base/task_scheduler/scheduler_worker_pool_impl.h View 1 2 chunks +8 lines, -1 line 0 comments Download
M base/task_scheduler/scheduler_worker_pool_impl.cc View 2 chunks +7 lines, -1 line 0 comments Download

Messages

Total messages: 14 (4 generated)
fdoray
PTAL
4 years, 2 months ago (2016-10-13 14:22:55 UTC) #2
robliao
Thanks for the small fixes coming through! https://codereview.chromium.org/2414063002/diff/1/base/task_scheduler/scheduler_worker_pool_impl.h File base/task_scheduler/scheduler_worker_pool_impl.h (right): https://codereview.chromium.org/2414063002/diff/1/base/task_scheduler/scheduler_worker_pool_impl.h#newcode117 base/task_scheduler/scheduler_worker_pool_impl.h:117: // Wakes ...
4 years, 2 months ago (2016-10-13 17:38:41 UTC) #3
fdoray
PTAnL https://codereview.chromium.org/2414063002/diff/1/base/task_scheduler/scheduler_worker_pool_impl.h File base/task_scheduler/scheduler_worker_pool_impl.h (right): https://codereview.chromium.org/2414063002/diff/1/base/task_scheduler/scheduler_worker_pool_impl.h#newcode117 base/task_scheduler/scheduler_worker_pool_impl.h:117: // Wakes up |worker| and removes it from ...
4 years, 2 months ago (2016-10-13 18:46:55 UTC) #4
robliao
lgtm
4 years, 2 months ago (2016-10-13 19:02:20 UTC) #5
commit-bot: I haz the power
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.org/2414063002/20001
4 years, 2 months ago (2016-10-13 19:03:18 UTC) #7
commit-bot: I haz the power
Committed patchset #2 (id:20001)
4 years, 2 months ago (2016-10-13 19:52:12 UTC) #8
commit-bot: I haz the power
Patchset 2 (id:??) landed as https://crrev.com/b7bd6bb60139b16375cd666f8f4ff79e072f18a0 Cr-Commit-Position: refs/heads/master@{#425132}
4 years, 2 months ago (2016-10-13 19:53:56 UTC) #10
gab
lgtm because it's better than before but there's still a race where the same worker ...
4 years, 2 months ago (2016-10-17 16:53:21 UTC) #12
fdoray
On 2016/10/17 16:53:21, gab (OOO) wrote: > lgtm because it's better than before but there's ...
4 years, 2 months ago (2016-10-17 17:23:13 UTC) #13
gab
4 years, 2 months ago (2016-10-17 18:33:43 UTC) #14
Message was sent while issue was closed.
On 2016/10/17 17:23:13, fdoray wrote:
> On 2016/10/17 16:53:21, gab (OOO) wrote:
> > lgtm because it's better than before but there's still a race where the same
> > worker could be posted SINGLE_THREADED work in parallel with being chosen to
> > process a SEQUENCED/PARALLEL task (the stack is locked during the operation
> > itself so there is no data corruption but the thread is still assigned more
> than
> > one task while other threads are sleeping).
> > 
> > It might be overkill to try and fix this but one solution is something like:
> > return a bool from RemoveFromIdleWorkersStack() to know whether the worker
was
> > currently idle and then to see if the SINGLE_THREADED task is next in
priority
> > with pending work behind it (if so, wake up another thread).
> 
> It makes sense to wake up another worker when a SINGLE_THREADED task is posted
> to a worker that has been selected to run a SEQUENCED/PARALLEL task but hasn't
> started to run it yet (after that it's too late). I would be curious to know
how
> often that occurs (shouldn't happen often if time from wake up to Run() is
> short).

I agree that it probably won't happen often. How do we infer if it does? Our
current latency histograms might be helpful but not until we have
SINGLE_THREADED work sent to the scheduler.

In a world where we eventually decide to "assign" multiple tasks to a single
worker (e.g. if it turns out that NumTasksBetweenWaits is too low) it would
still be nice to correctly account for the number of tasks "assigned" to a given
worker instead of just saying "meh +/- 1".

It might actually happen often in the initial redirection world where over half
of the work will be SINGLE_THREADED.

Powered by Google App Engine
This is Rietveld 408576698