|
|
Chromium Code Reviews|
Created:
4 years, 7 months ago by stanisc Modified:
4 years, 7 months ago Reviewers:
Mark Mentovai CC:
chromium-reviews, sadrul Base URL:
https://chromium.googlesource.com/chromium/src.git@master Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionTiming issue in IncomingTaskQueue::AddToIncomingQueue
This fix minimizes an extra delay in calculated task's
delayed runtime in case of lock contention and the current
thread switching out.
A better solution would be to pass "now" from outside but
that would be a much larger code change.
The fix should also reduce chances of lock contention in
this code a tiny bit by reducing the lock scope.
I've done a number of runs of smoothness benchmark before
and after the fix and it seems there is a very small
improvement in "queuing durations" and "percentage smooth" metrics.
BUG=613399
Committed: https://crrev.com/94ab140542d6f2c2b72d33b6f5c0935dd34af003
Cr-Commit-Position: refs/heads/master@{#395393}
Patch Set 1 #
Messages
Total messages: 14 (9 generated)
Description was changed from ========== Incoming queue fix BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ==========
Description was changed from ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ==========
Description was changed from ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ==========
Description was changed from ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ==========
Description was changed from ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ==========
stanisc@chromium.org changed reviewers: + mark@chromium.org
PTAL!
LGTM
The CQ bit was checked by stanisc@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/2002743002/1 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/2002743002/1
Message was sent while issue was closed.
Description was changed from ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ==========
Message was sent while issue was closed.
Committed patchset #1 (id:1)
Message was sent while issue was closed.
Description was changed from ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 ========== to ========== Timing issue in IncomingTaskQueue::AddToIncomingQueue This fix minimizes an extra delay in calculated task's delayed runtime in case of lock contention and the current thread switching out. A better solution would be to pass "now" from outside but that would be a much larger code change. The fix should also reduce chances of lock contention in this code a tiny bit by reducing the lock scope. I've done a number of runs of smoothness benchmark before and after the fix and it seems there is a very small improvement in "queuing durations" and "percentage smooth" metrics. BUG=613399 Committed: https://crrev.com/94ab140542d6f2c2b72d33b6f5c0935dd34af003 Cr-Commit-Position: refs/heads/master@{#395393} ==========
Message was sent while issue was closed.
Patchset 1 (id:??) landed as https://crrev.com/94ab140542d6f2c2b72d33b6f5c0935dd34af003 Cr-Commit-Position: refs/heads/master@{#395393} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
