[system health] Add power system health benchmarks

[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158, 589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq

Committed: https://crrev.com/71253911d21dfc93fdeccb6c46e518c2a078a3b9
Cr-Commit-Position: refs/heads/master@{#415561}

[charliea (OOO until 10-5), 2016-08-12 01:34:46]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

BUG=637158
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

BUG=637158
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

[charliea (OOO until 10-5), 2016-08-12 01:35:49]

charliea@chromium.org changed reviewers:
+ petrcermak@chromium.org

[charliea (OOO until 10-5), 2016-08-12 01:39:40]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

BUG=637158
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

[nednguyen, 2016-08-12 02:01:54]

On 2016/08/12 01:35:49, charliea wrote:

Wouldn't enabling battor tracing & battor power metrics be resilient to the case
of device not having the battor? i.e: it will just output nothing instead of
throwing exception?

[petrcermak, 2016-08-12 09:03:00]

petrcermak@chromium.org changed reviewers:
+ nednguyen@google.com

[petrcermak, 2016-08-12 09:03:00]

Looks good overall. I've left you two comments.

On 2016/08/12 02:01:54, nednguyen (ooo til 8-13) wrote:
> On 2016/08/12 01:35:49, charliea wrote:
> 
> Wouldn't enabling battor tracing & battor power metrics be resilient to the
case
> of device not having the battor? i.e: it will just output nothing instead of
> throwing exception?

If this would work, then it would be great. If not, then I guess we have to
either modify telemetry (so that the benchmark can determine whether it can use
BattOr in its setup), or we'll have a separate power benchmark if necessary.
I'll leave this up to Ned. Apart from this, LGTM :-)

Thanks,
Petr

https://codereview.chromium.org/2239053003/diff/1/tools/perf/benchmarks/syste...
File tools/perf/benchmarks/system_health.py (right):

https://codereview.chromium.org/2239053003/diff/1/tools/perf/benchmarks/syste...
tools/perf/benchmarks/system_health.py:59: class
_PowerSystemHealthBenchmark(perf_benchmark.PerfBenchmark):
Instead of interleaving the classes:

_MemorySystemHealthBenchmark
_PowerSystemHealthBenchmark
DesktopMemorySystemHealthBenchmark
...
DesktopPowerSystemHealthBenchmark
...

Please keep each group together:

_MemorySystemHealthBenchmark
DesktopMemorySystemHealthBenchmark
...
_PowerSystemHealthBenchmark
DesktopPowerSystemHealthBenchmark
...

https://codereview.chromium.org/2239053003/diff/1/tools/perf/benchmarks/syste...
tools/perf/benchmarks/system_health.py:88: return not
_IGNORED_STATS_RE.search(value.name)
How many values does your metric generate? If it's only a couple, then you don't
need this (we need it in memory because we are producing hundreds of values).

[sullivan, 2016-08-12 11:15:49]

On 2016/08/12 09:03:00, petrcermak wrote:
> Looks good overall. I've left you two comments.
> 
> On 2016/08/12 02:01:54, nednguyen (ooo til 8-13) wrote:
> > On 2016/08/12 01:35:49, charliea wrote:
> > 
> > Wouldn't enabling battor tracing & battor power metrics be resilient to the
> case
> > of device not having the battor? i.e: it will just output nothing instead of
> > throwing exception?
> 
> If this would work, then it would be great. If not, then I guess we have to
> either modify telemetry (so that the benchmark can determine whether it can
use
> BattOr in its setup), or we'll have a separate power benchmark if necessary.
> I'll leave this up to Ned. Apart from this, LGTM :-)

+1 for this working--I think it'll make having a large number of stories
combined with a large number of bots on the waterfall much more manageable.

[charliea (OOO until 10-5), 2016-08-12 14:18:43]

PTAL

https://codereview.chromium.org/2239053003/diff/1/tools/perf/benchmarks/syste...
File tools/perf/benchmarks/system_health.py (right):

https://codereview.chromium.org/2239053003/diff/1/tools/perf/benchmarks/syste...
tools/perf/benchmarks/system_health.py:59: class
_PowerSystemHealthBenchmark(perf_benchmark.PerfBenchmark):
On 2016/08/12 09:03:00, petrcermak wrote:
> Instead of interleaving the classes:
> 
> _MemorySystemHealthBenchmark
> _PowerSystemHealthBenchmark
> DesktopMemorySystemHealthBenchmark
> ...
> DesktopPowerSystemHealthBenchmark
> ...
> 
> Please keep each group together:
> 
> _MemorySystemHealthBenchmark
> DesktopMemorySystemHealthBenchmark
> ...
> _PowerSystemHealthBenchmark
> DesktopPowerSystemHealthBenchmark
> ...

Done.

https://codereview.chromium.org/2239053003/diff/1/tools/perf/benchmarks/syste...
tools/perf/benchmarks/system_health.py:88: return not
_IGNORED_STATS_RE.search(value.name)
On 2016/08/12 09:03:00, petrcermak wrote:
> How many values does your metric generate? If it's only a couple, then you
don't
> need this (we need it in memory because we are producing hundreds of values).

Done.

[petrcermak, 2016-08-12 14:35:00]

Please update the patch description and title and add 589726 to BUG=... (so that
it posts an update to the overall SH tracking bug). Apart from that, LGTM.

Thanks,
Petr

https://codereview.chromium.org/2239053003/diff/40001/tools/perf/benchmarks/s...
File tools/perf/benchmarks/system_health.py (right):

https://codereview.chromium.org/2239053003/diff/40001/tools/perf/benchmarks/s...
tools/perf/benchmarks/system_health.py:27: 2) Be run in a separate test suite.
maybe add "(such as memory)"?

[charliea (OOO until 10-5), 2016-08-12 15:07:04]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

[charliea (OOO until 10-5), 2016-08-12 15:07:28]

https://codereview.chromium.org/2239053003/diff/40001/tools/perf/benchmarks/s...
File tools/perf/benchmarks/system_health.py (right):

https://codereview.chromium.org/2239053003/diff/40001/tools/perf/benchmarks/s...
tools/perf/benchmarks/system_health.py:27: 2) Be run in a separate test suite.
On 2016/08/12 14:35:00, petrcermak wrote:
> maybe add "(such as memory)"?

Done.

[charliea (OOO until 10-5), 2016-08-12 15:07:35]

The CQ bit was checked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-08-12 15:07:36]

The patchset sent to the CQ was uploaded after l-g-t-m from
petrcermak@chromium.org
Link to the patchset: https://codereview.chromium.org/2239053003/#ps60001
(title: "Add memory to separate test suite comment")

[commit-bot: I haz the power, 2016-08-12 15:07:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-12 17:03:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-12 17:03:02]

Try jobs failed on following builders:
  mac_retina_perf_cq on master.tryserver.chromium.perf (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_retina_perf_...)

[charliea (OOO until 10-5), 2016-08-15 15:33:39]

The CQ bit was checked by charliea@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-15 15:33:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-15 16:25:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-15 16:25:59]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[nednguyen, 2016-08-15 20:33:59]

The CQ bit was checked by nednguyen@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-08-15 20:34:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-15 21:29:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-15 21:29:41]

Dry run: Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[charliea (OOO until 10-5), 2016-08-16 19:22:17]

The CQ bit was checked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-08-16 19:22:18]

The patchset sent to the CQ was uploaded after l-g-t-m from
petrcermak@chromium.org
Link to the patchset: https://codereview.chromium.org/2239053003/#ps100001
(title: "Record only rail events")

[commit-bot: I haz the power, 2016-08-16 19:22:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-16 20:18:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-16 20:18:49]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[charliea (OOO until 10-5), 2016-08-16 20:26:25]

The CQ bit was checked by charliea@chromium.org

[commit-bot: I haz the power, 2016-08-16 20:26:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[charliea (OOO until 10-5), 2016-08-16 20:27:11]

The CQ bit was unchecked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-08-16 20:29:20]

The CQ bit was checked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-08-16 20:29:20]

The patchset sent to the CQ was uploaded after l-g-t-m from
petrcermak@chromium.org
Link to the patchset: https://codereview.chromium.org/2239053003/#ps120001
(title: "Added missing "category_filter"")

[commit-bot: I haz the power, 2016-08-16 20:29:40]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[charliea (OOO until 10-5), 2016-08-16 21:22:44]

The CQ bit was unchecked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-08-19 18:53:32]

The CQ bit was checked by charliea@chromium.org

[charliea (OOO until 10-5), 2016-08-19 18:53:32]

The patchset sent to the CQ was uploaded after l-g-t-m from
petrcermak@chromium.org
Link to the patchset: https://codereview.chromium.org/2239053003/#ps160001
(title: " ")

[commit-bot: I haz the power, 2016-08-19 18:54:03]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-19 20:56:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-19 20:56:10]

Try jobs failed on following builders:
  mac_retina_perf_cq on master.tryserver.chromium.perf (JOB_TIMED_OUT, no build
URL)

[nednguyen, 2016-08-25 11:18:26]

nednguyen@google.com changed reviewers:
+ rnephew@chromium.org

[charliea (OOO until 10-5), 2016-08-29 19:29:36]

The CQ bit was checked by charliea@chromium.org

[commit-bot: I haz the power, 2016-08-29 19:41:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 03:20:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 03:20:47]

Try jobs failed on following builders:
  android_s5_perf_cq on master.tryserver.chromium.perf (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.perf/builders/android_s5_perf_...)

[charliea (OOO until 10-5), 2016-08-30 15:51:26]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:android_s5_perf_cq;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

[charliea (OOO until 10-5), 2016-08-30 15:51:42]

The CQ bit was checked by charliea@chromium.org

[commit-bot: I haz the power, 2016-08-30 15:52:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 15:52:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 15:52:04]

Your CL can not be processed by CQ because of:
 * Failed to parse additional trybots

[nednguyen, 2016-08-30 23:51:14]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf;master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

[nednguyen, 2016-08-30 23:51:19]

The CQ bit was checked by nednguyen@google.com

[commit-bot: I haz the power, 2016-08-30 23:51:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 01:53:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-31 01:53:02]

Try jobs failed on following builders:
  mac_retina_perf_cq on master.tryserver.chromium.perf (JOB_TIMED_OUT, no build
URL)

[nednguyen, 2016-08-31 04:36:29]

The CQ bit was checked by nednguyen@google.com

[commit-bot: I haz the power, 2016-08-31 04:36:49]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-31 04:40:34]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

[commit-bot: I haz the power, 2016-08-31 04:40:35]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-08-31 04:43:09]

Description was changed from

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq
==========

to

==========
[system health] Add power system health benchmarks

Even though the metrics that we have aren't ideal quite yet (total
energy consumed, average power draw), we still want system health
benchmarks running ASAP in order to prevent major regressions.

We discussed having two runs of the system health benchmarks:
memory and non-memory, with memory being isolated due to its high
overhead. At least for the time being, that's not possible with power
benchmarks because we need to decide in the benchmark constructor
whether to enable BattOr tracing, even though we don't have any ability
to know whether a BattOr is attached. Because of that, we're forced to
disable the test on any devices without BattOrs in the @ShouldDisable
predicate.

BUG=637158,589726
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.perf:linux_perf_cq;master.tryserver.chromium.perf:mac_retina_perf_cq;master.tryserver.chromium.perf:winx64_10_perf_cq

Committed: https://crrev.com/71253911d21dfc93fdeccb6c46e518c2a078a3b9
Cr-Commit-Position: refs/heads/master@{#415561}
==========

[commit-bot: I haz the power, 2016-08-31 04:43:10]

Patchset 9 (id:??) landed as
https://crrev.com/71253911d21dfc93fdeccb6c46e518c2a078a3b9
Cr-Commit-Position: refs/heads/master@{#415561}