Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1359473003:
Enable GPU rasterization for more telemetry tests. (Closed)
DescriptionEnable GPU rasterization for more telemetry tests.
Creates GPU force-enabled versions of:
PowerGpuRasterizationTop10 (gpu/non-gpu are both mac-only)
PowerGpuRasterizationTop25 (gpu/non-gpu are both mac-only)
SmoothnessGpuRasterizationToughPinchZoomCases (android/aura/mac - no pinch support for win)
SmoothnessGpuRasterizationToughScrollingCases (android/mac)
Un-restricts the following from Android only:
SmoothnessGpuRasterizationTop25 (android/mac)
BUG=537856
CQ_EXTRA_TRYBOTS=tryserver.chromium.perf:linux_perf_bisect;tryserver.chromium.perf:win_perf_bisect
Committed: https://crrev.com/296d91dd5cab7fccc42e22442c3c29e661934ccc
Cr-Commit-Position: refs/heads/master@{#352673}
Patch Set 1 #Patch Set 2 : add tag #Patch Set 3 : Add pinch-zoom for mac #Patch Set 4 : rebase #
Total comments: 4
Patch Set 5 : feedback #Patch Set 6 : rebase #Messages
Total messages: 49 (20 generated)
ericrk@chromium.org changed reviewers: + nednguyen@google.com, vmiura@chromium.org
Here's a CL to turn on GPU rasterization for a number of previously CPU-only tests. Per previous conversations with perf sherifs, this test only adds new metrics (doesn't modify existing ones), so it shouldn't cause any regressions.
lgtm % comments https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... File tools/perf/benchmarks/smoothness.py (right): https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... tools/perf/benchmarks/smoothness.py:140: class SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): Should we stick to Android & Mac for now? https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... tools/perf/benchmarks/smoothness.py:330: class SmoothnessGpuRasterizationToughScrollingCases( Same, Android & Mac?
nednguyen@google.com changed reviewers: + aiolos@chromium.org
Updated. https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... File tools/perf/benchmarks/smoothness.py (right): https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... tools/perf/benchmarks/smoothness.py:140: class SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): On 2015/09/23 21:01:52, vmiura wrote: > Should we stick to Android & Mac for now? Either way seems fine to me - not bad to start collecting stats from others earlier - but might slow down the queues? Will switch to Android+Mac for now. https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... tools/perf/benchmarks/smoothness.py:330: class SmoothnessGpuRasterizationToughScrollingCases( On 2015/09/23 21:01:52, vmiura wrote: > Same, Android & Mac? Done.
On 2015/09/28 22:43:27, ericrk wrote: > Updated. > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > File tools/perf/benchmarks/smoothness.py (right): > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > tools/perf/benchmarks/smoothness.py:140: class > SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): > On 2015/09/23 21:01:52, vmiura wrote: > > Should we stick to Android & Mac for now? > > Either way seems fine to me - not bad to start collecting stats from others > earlier - but might slow down the queues? Will switch to Android+Mac for now. > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > tools/perf/benchmarks/smoothness.py:330: class > SmoothnessGpuRasterizationToughScrollingCases( > On 2015/09/23 21:01:52, vmiura wrote: > > Same, Android & Mac? > > Done. friendly ping - Ned, are you able to take a look?
On 2015/09/30 17:50:12, ericrk wrote: > On 2015/09/28 22:43:27, ericrk wrote: > > Updated. > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > File tools/perf/benchmarks/smoothness.py (right): > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > tools/perf/benchmarks/smoothness.py:140: class > > SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): > > On 2015/09/23 21:01:52, vmiura wrote: > > > Should we stick to Android & Mac for now? > > > > Either way seems fine to me - not bad to start collecting stats from others > > earlier - but might slow down the queues? Will switch to Android+Mac for now. > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > tools/perf/benchmarks/smoothness.py:330: class > > SmoothnessGpuRasterizationToughScrollingCases( > > On 2015/09/23 21:01:52, vmiura wrote: > > > Same, Android & Mac? > > > > Done. > > friendly ping - Ned, are you able to take a look? Can you justify the needs of adding these benchmark? e.g: can you point a sample CL that would regress the metrics produced by these benchmarks?
On 2015/09/30 17:53:59, nednguyen wrote: > On 2015/09/30 17:50:12, ericrk wrote: > > On 2015/09/28 22:43:27, ericrk wrote: > > > Updated. > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > File tools/perf/benchmarks/smoothness.py (right): > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > tools/perf/benchmarks/smoothness.py:140: class > > > SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > Should we stick to Android & Mac for now? > > > > > > Either way seems fine to me - not bad to start collecting stats from others > > > earlier - but might slow down the queues? Will switch to Android+Mac for > now. > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > tools/perf/benchmarks/smoothness.py:330: class > > > SmoothnessGpuRasterizationToughScrollingCases( > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > Same, Android & Mac? > > > > > > Done. > > > > friendly ping - Ned, are you able to take a look? > > Can you justify the needs of adding these benchmark? e.g: can you point a sample > CL that would regress the metrics produced by these benchmarks? We are going to be switching from Software > GPU raster, so at some point in the near-ish future, all of the metrics which don't specify GPU specifically will switch to GPU. The goal of this CL is to get parallel versions of these metrics running now for two reasons: - Understand any differences between the Software and GPU raster paths before we flip the switch. - Start tracking regressions in GPU raster, which may now be ignored. To give more details on the second issue, each of these GPU raster specific versions is of equal value to the default version in terms of catching regressions - GPU raster drastically affects how rendering works in Chrome - it changes the tile size used for compositing, it changes the characteristics of how long it takes to render a tile, and it increases contention for GPU time while reducing CPU time. Without a metric that hits GPU raster, we are leaving large areas of our codebase unmonitored for regressions. To give a few specifics: - Our current power metrics are Software Raster only on Mac. This means that a change in Skia's GPU raster which regresses power wouldn't be caught. From talking to ccameron, we expect to see noticeably different power usage with GPU raster on mac. - Our smoothness metrics are very broad and can catch regressions throughout CC and raster. For instance, consider crbug.com/483520, the changes in this bug affected the smoothness.tough_scrolling cases (see crbug.com/504631). As of now, we only understand how this impacted this metric with software raster enabled. Because GPU raster changes a number of things, most notably tile size and skewport time, it would be impacted by this change in a different way. We'd like to understand the impact here as well as in software. Let me know if this makes sense. Thanks! -Eric
On 2015/09/30 18:22:52, ericrk wrote: > On 2015/09/30 17:53:59, nednguyen wrote: > > On 2015/09/30 17:50:12, ericrk wrote: > > > On 2015/09/28 22:43:27, ericrk wrote: > > > > Updated. > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > File tools/perf/benchmarks/smoothness.py (right): > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > tools/perf/benchmarks/smoothness.py:140: class > > > > SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): > > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > > Should we stick to Android & Mac for now? > > > > > > > > Either way seems fine to me - not bad to start collecting stats from > others > > > > earlier - but might slow down the queues? Will switch to Android+Mac for > > now. > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > tools/perf/benchmarks/smoothness.py:330: class > > > > SmoothnessGpuRasterizationToughScrollingCases( > > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > > Same, Android & Mac? > > > > > > > > Done. > > > > > > friendly ping - Ned, are you able to take a look? > > > > Can you justify the needs of adding these benchmark? e.g: can you point a > sample > > CL that would regress the metrics produced by these benchmarks? > > We are going to be switching from Software > GPU raster, so at some point in the > near-ish future, all of the metrics which don't specify GPU specifically will > switch to GPU. The goal of this CL is to get parallel versions of these metrics > running now for two reasons: > - Understand any differences between the Software and GPU raster paths before we > flip the switch. > - Start tracking regressions in GPU raster, which may now be ignored. > > To give more details on the second issue, each of these GPU raster specific > versions is of equal value to the default version in terms of catching > regressions - GPU raster drastically affects how rendering works in Chrome - it > changes the tile size used for compositing, it changes the characteristics of > how long it takes to render a tile, and it increases contention for GPU time > while reducing CPU time. Without a metric that hits GPU raster, we are leaving > large areas of our codebase unmonitored for regressions. > > To give a few specifics: > - Our current power metrics are Software Raster only on Mac. This means that a > change in Skia's GPU raster which regresses power wouldn't be caught. From > talking to ccameron, we expect to see noticeably different power usage with GPU > raster on mac. > - Our smoothness metrics are very broad and can catch regressions throughout CC > and raster. For instance, consider crbug.com/483520, the changes in this bug > affected the smoothness.tough_scrolling cases (see crbug.com/504631). As of now, > we only understand how this impacted this metric with software raster enabled. > Because GPU raster changes a number of things, most notably tile size and Can you recreate the change and check how this benchmark reflect it with your local machine? > skewport time, it would be impacted by this change in a different way. We'd like > to understand the impact here as well as in software. > > Let me know if this makes sense. > Thanks! > -Eric This explanation make sense. Please file a cover bug & put your description to that bug & link this CL to the bug.
On 2015/09/30 18:35:22, nednguyen wrote: > On 2015/09/30 18:22:52, ericrk wrote: > > On 2015/09/30 17:53:59, nednguyen wrote: > > > On 2015/09/30 17:50:12, ericrk wrote: > > > > On 2015/09/28 22:43:27, ericrk wrote: > > > > > Updated. > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > > File tools/perf/benchmarks/smoothness.py (right): > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > > tools/perf/benchmarks/smoothness.py:140: class > > > > > SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): > > > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > > > Should we stick to Android & Mac for now? > > > > > > > > > > Either way seems fine to me - not bad to start collecting stats from > > others > > > > > earlier - but might slow down the queues? Will switch to Android+Mac for > > > now. > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > > tools/perf/benchmarks/smoothness.py:330: class > > > > > SmoothnessGpuRasterizationToughScrollingCases( > > > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > > > Same, Android & Mac? > > > > > > > > > > Done. > > > > > > > > friendly ping - Ned, are you able to take a look? > > > > > > Can you justify the needs of adding these benchmark? e.g: can you point a > > sample > > > CL that would regress the metrics produced by these benchmarks? > > > > We are going to be switching from Software > GPU raster, so at some point in > the > > near-ish future, all of the metrics which don't specify GPU specifically will > > switch to GPU. The goal of this CL is to get parallel versions of these > metrics > > running now for two reasons: > > - Understand any differences between the Software and GPU raster paths before > we > > flip the switch. > > - Start tracking regressions in GPU raster, which may now be ignored. > > > > To give more details on the second issue, each of these GPU raster specific > > versions is of equal value to the default version in terms of catching > > regressions - GPU raster drastically affects how rendering works in Chrome - > it > > changes the tile size used for compositing, it changes the characteristics of > > how long it takes to render a tile, and it increases contention for GPU time > > while reducing CPU time. Without a metric that hits GPU raster, we are leaving > > large areas of our codebase unmonitored for regressions. > > > > To give a few specifics: > > - Our current power metrics are Software Raster only on Mac. This means that a > > change in Skia's GPU raster which regresses power wouldn't be caught. From > > talking to ccameron, we expect to see noticeably different power usage with > GPU > > raster on mac. > > - Our smoothness metrics are very broad and can catch regressions throughout > CC > > and raster. For instance, consider crbug.com/483520, the changes in this bug > > affected the smoothness.tough_scrolling cases (see crbug.com/504631). As of > now, > > we only understand how this impacted this metric with software raster enabled. > > Because GPU raster changes a number of things, most notably tile size and > > Can you recreate the change and check how this benchmark reflect it with your > local machine? > > > skewport time, it would be impacted by this change in a different way. We'd > like > > to understand the impact here as well as in software. > > > > Let me know if this makes sense. > > Thanks! > > -Eric > > This explanation make sense. Please file a cover bug & put your description to > that bug & link this CL to the bug. Created a bug with this information and linked it to this CL. I did a quick repro with a similar situation to the CL I mentioned earlier (changing the skewport size) and found that by doubling the skewport again, we see an improvement in "mean pixels checkerboarded" in both GPU and software, with a slightly larger improvement in GPU than in software (53 vs 59%). Additionally, only software shows a regression - "frame time latency" get's worse by 9%. GPU shows no high-confidence regressions, and actually shows a low-confidence improvement in frame time latency (2.5%). Things like this could be useful to understand, as if a change is always a win on GPU but only sometimes a win on Software, we may look at the change less favorably if dealing only with software data.
On 2015/10/01 20:30:18, ericrk wrote: > On 2015/09/30 18:35:22, nednguyen wrote: > > On 2015/09/30 18:22:52, ericrk wrote: > > > On 2015/09/30 17:53:59, nednguyen wrote: > > > > On 2015/09/30 17:50:12, ericrk wrote: > > > > > On 2015/09/28 22:43:27, ericrk wrote: > > > > > > Updated. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > > > File tools/perf/benchmarks/smoothness.py (right): > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > > > tools/perf/benchmarks/smoothness.py:140: class > > > > > > SmoothnessGpuRasterizationTop25(perf_benchmark.PerfBenchmark): > > > > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > > > > Should we stick to Android & Mac for now? > > > > > > > > > > > > Either way seems fine to me - not bad to start collecting stats from > > > others > > > > > > earlier - but might slow down the queues? Will switch to Android+Mac > for > > > > now. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://codereview.chromium.org/1359473003/diff/60001/tools/perf/benchmarks/s... > > > > > > tools/perf/benchmarks/smoothness.py:330: class > > > > > > SmoothnessGpuRasterizationToughScrollingCases( > > > > > > On 2015/09/23 21:01:52, vmiura wrote: > > > > > > > Same, Android & Mac? > > > > > > > > > > > > Done. > > > > > > > > > > friendly ping - Ned, are you able to take a look? > > > > > > > > Can you justify the needs of adding these benchmark? e.g: can you point a > > > sample > > > > CL that would regress the metrics produced by these benchmarks? > > > > > > We are going to be switching from Software > GPU raster, so at some point in > > the > > > near-ish future, all of the metrics which don't specify GPU specifically > will > > > switch to GPU. The goal of this CL is to get parallel versions of these > > metrics > > > running now for two reasons: > > > - Understand any differences between the Software and GPU raster paths > before > > we > > > flip the switch. > > > - Start tracking regressions in GPU raster, which may now be ignored. > > > > > > To give more details on the second issue, each of these GPU raster specific > > > versions is of equal value to the default version in terms of catching > > > regressions - GPU raster drastically affects how rendering works in Chrome - > > it > > > changes the tile size used for compositing, it changes the characteristics > of > > > how long it takes to render a tile, and it increases contention for GPU time > > > while reducing CPU time. Without a metric that hits GPU raster, we are > leaving > > > large areas of our codebase unmonitored for regressions. > > > > > > To give a few specifics: > > > - Our current power metrics are Software Raster only on Mac. This means that > a > > > change in Skia's GPU raster which regresses power wouldn't be caught. From > > > talking to ccameron, we expect to see noticeably different power usage with > > GPU > > > raster on mac. > > > - Our smoothness metrics are very broad and can catch regressions throughout > > CC > > > and raster. For instance, consider crbug.com/483520, the changes in this bug > > > affected the smoothness.tough_scrolling cases (see crbug.com/504631). As of > > now, > > > we only understand how this impacted this metric with software raster > enabled. > > > Because GPU raster changes a number of things, most notably tile size and > > > > Can you recreate the change and check how this benchmark reflect it with your > > local machine? > > > > > skewport time, it would be impacted by this change in a different way. We'd > > like > > > to understand the impact here as well as in software. > > > > > > Let me know if this makes sense. > > > Thanks! > > > -Eric > > > > This explanation make sense. Please file a cover bug & put your description to > > that bug & link this CL to the bug. > > Created a bug with this information and linked it to this CL. > > I did a quick repro with a similar situation to the CL I mentioned earlier > (changing the skewport size) and found that by doubling the skewport again, we > see an improvement in "mean pixels checkerboarded" in both GPU and software, > with a slightly larger improvement in GPU than in software (53 vs 59%). > Additionally, only software shows a regression - "frame time latency" get's > worse by 9%. GPU shows no high-confidence regressions, and actually shows a > low-confidence improvement in frame time latency (2.5%). Things like this could > be useful to understand, as if a change is always a win on GPU but only > sometimes a win on Software, we may look at the change less favorably if dealing > only with software data. Thanks. Please put these finding in the covered bug for later reference. lgtm
The CQ bit was checked by ericrk@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from vmiura@chromium.org Link to the patchset: https://codereview.chromium.org/1359473003/#ps100001 (title: "rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...)
Patchset #7 (id:120001) has been deleted
The CQ bit was checked by ericrk@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from vmiura@chromium.org Link to the patchset: https://codereview.chromium.org/1359473003/#ps100001 (title: "rebase")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...)
On 2015/10/06 00:34:19, commit-bot: I haz the power wrote: > Try jobs failed on following builders: > mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, > http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...) Can you check the test failures? If you think they are unrelated to your modified benchmarks, feel free to remove the bot name from CQ_EXTRA_TRYBOTS list.
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
On 2015/10/06 at 03:04:19, nednguyen wrote: > On 2015/10/06 00:34:19, commit-bot: I haz the power wrote: > > Try jobs failed on following builders: > > mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, > > http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...) > > Can you check the test failures? If you think they are unrelated to your modified benchmarks, feel free to remove the bot name from CQ_EXTRA_TRYBOTS list. They look unrelated, but from looking at the other jobs on the bot, things seem to be green now. Going to try submitting again.
On 2015/10/06 at 16:37:45, ericrk wrote: > On 2015/10/06 at 03:04:19, nednguyen wrote: > > On 2015/10/06 00:34:19, commit-bot: I haz the power wrote: > > > Try jobs failed on following builders: > > > mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, > > > http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...) > > > > Can you check the test failures? If you think they are unrelated to your modified benchmarks, feel free to remove the bot name from CQ_EXTRA_TRYBOTS list. > > They look unrelated, but from looking at the other jobs on the bot, things seem to be green now. Going to try submitting again. Ok, realized that the green runs are running different subsets of tests. From looking at the failures, they don't appear related to my CL. Going to drop the bots from the CQ_EXTRA_TRYBOTS list. I think we need at least one new bug for the mac failures, will look into filing something. Android also appears flaky, but is in a better state than the mac bot.
The CQ bit was unchecked by ericrk@chromium.org
The CQ bit was checked by ericrk@chromium.org
The CQ bit was unchecked by ericrk@chromium.org
On 2015/10/06 19:15:56, ericrk wrote: > On 2015/10/06 at 16:37:45, ericrk wrote: > > On 2015/10/06 at 03:04:19, nednguyen wrote: > > > On 2015/10/06 00:34:19, commit-bot: I haz the power wrote: > > > > Try jobs failed on following builders: > > > > mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, > > > > > http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...) > > > > > > Can you check the test failures? If you think they are unrelated to your > modified benchmarks, feel free to remove the bot name from CQ_EXTRA_TRYBOTS > list. > > > > They look unrelated, but from looking at the other jobs on the bot, things > seem to be green now. Going to try submitting again. > > Ok, realized that the green runs are running different subsets of tests. > > From looking at the failures, they don't appear related to my CL. Going to drop > the bots from the CQ_EXTRA_TRYBOTS list. I think we need at least one new bug > for the mac failures, will look into filing something. Android also appears > flaky, but is in a better state than the mac bot. Thank you for filing a bug!
On 2015/10/06 at 19:36:49, aiolos wrote: > On 2015/10/06 19:15:56, ericrk wrote: > > On 2015/10/06 at 16:37:45, ericrk wrote: > > > On 2015/10/06 at 03:04:19, nednguyen wrote: > > > > On 2015/10/06 00:34:19, commit-bot: I haz the power wrote: > > > > > Try jobs failed on following builders: > > > > > mac_10_10_perf_bisect on tryserver.chromium.perf (JOB_FAILED, > > > > > > > http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_10_perf_b...) > > > > > > > > Can you check the test failures? If you think they are unrelated to your > > modified benchmarks, feel free to remove the bot name from CQ_EXTRA_TRYBOTS > > list. > > > > > > They look unrelated, but from looking at the other jobs on the bot, things > > seem to be green now. Going to try submitting again. > > > > Ok, realized that the green runs are running different subsets of tests. > > > > From looking at the failures, they don't appear related to my CL. Going to drop > > the bots from the CQ_EXTRA_TRYBOTS list. I think we need at least one new bug > > for the mac failures, will look into filing something. Android also appears > > flaky, but is in a better state than the mac bot. > > Thank you for filing a bug! Filed crbug.com/539982 and crbug.com/539980
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1359473003/100001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1359473003/100001
Message was sent while issue was closed.
Committed patchset #6 (id:100001)
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/296d91dd5cab7fccc42e22442c3c29e661934ccc Cr-Commit-Position: refs/heads/master@{#352673} |
