This reverts commit f39bbe5a31.
Reason for revert: Broke lots of bots
Original change's description:
> Reland "[infra] Run recipes through Kitchen"
>
> Bug: skia:7050
> Change-Id: I331014c408dd5b6f7baafd78ffd12f1235c5bfe7
> Reviewed-on: https://skia-review.googlesource.com/121481
> Commit-Queue: Eric Boren <borenet@google.com>
> Reviewed-by: Ben Wagner <benjaminwagner@google.com>
> Reviewed-by: Ravi Mistry <rmistry@google.com>
TBR=borenet@google.com,benjaminwagner@google.com,rmistry@google.com
Change-Id: I4548c66a9cb0b4f105e2bc3b1c7185d14549172f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7050
Reviewed-on: https://skia-review.googlesource.com/121463
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:7050
Change-Id: I331014c408dd5b6f7baafd78ffd12f1235c5bfe7
Reviewed-on: https://skia-review.googlesource.com/121481
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Bug: skia:7050
Change-Id: I50632444eb4ca7f9ae2b1b30b766e531092ccad4
Reviewed-on: https://skia-review.googlesource.com/82500
Commit-Queue: Eric Boren <borenet@google.com>
Reviewed-by: Ravi Mistry <rmistry@google.com>
Bug: skia:7720
Change-Id: I044ca5281354b21c9deffa408ad7ec20c51d2e2e
Reviewed-on: https://skia-review.googlesource.com/115122
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
They seem to be their own special cases for what
governors they support.
Bug: skia:
NOTRY=true
Change-Id: I7bb220e1d3ba6851c17c7e6ef327aab24ffdba42
Reviewed-on: https://skia-review.googlesource.com/83900
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This scaling logic correctly accounts for some devices
which have multiple CPUs. Previously, we were scaling
the smaller of these CPUs, which likely had a negative
impact on nanobench, given nanobench was single threaded
and the CPUs weren't allowed to idle much (because we
set the CPU).
This CL sets those additional CPUs to powersave when we run
nanobench and then correctly scales down the beefier
CPU we want to run nanobench on.
For DM, we just run it in ondemand mode, which will
hopefully be "as fast as possible", but allow the CPU
governor to scale down if overheating becomes a problem.
Bug: skia:7378
notry=TRUE
Change-Id: I45ca5d9fb32182233d1b2d094842c879f2b84da4
Reviewed-on: https://skia-review.googlesource.com/83240
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Add logic to run on Nexus 5xs in Golo.
Bug:788839
Change-Id: I12290d11a0b1b0f012ada216da3e5b2599979c5e
Reviewed-on: https://skia-review.googlesource.com/81861
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
The previous list was created from scaling_min_freq and scaling_max_freq
instead of cpuinfo_min_freq and cpuinfo_max_freq which are the actual mins
and maxes, not the current (transient) settings of the governor.
Before:
Test-Release: 61 minutes
Perf-Debug: 41 minutes
After:
Test-Release: 32 minutes
Perf-Debug: 16 minutes
NOTRY=true
Bug: skia:
Change-Id: I9b431e92d2abcecb4fe643389daddc912a1399e1
Reviewed-on: https://skia-review.googlesource.com/78141
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Some bots, especially the Nexus 7s, seemed to occasionally
fail when setting the CPU frequency. I was unable to
repro this behavior, so this is a shotgun approach.
We add a 5 second delay between setting and checking,
checking frequency using scaling_cur_freq instead of
scaling_setspeed, set the min_freq as well as max_freq,
and retry up to 3 times if setting cpu frequency fails.
NOTRY=true
Bug: skia:
Change-Id: Id4d85d8d509c9dba8e3a0e06b5992f5adadf36d2
Reviewed-on: https://skia-review.googlesource.com/78140
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: Iefef7d617e58de2b3be2e27aac075f822641e4ce
Reviewed-on: https://skia-review.googlesource.com/77641
Reviewed-by: Stephan Altmueller <stephana@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Bug: skia:
NOTRY=true
Change-Id: I1a1755dd03f2e6ebd8d9b2c9235cca8eb34f04ad
Reviewed-on: https://skia-review.googlesource.com/75280
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
This also makes *sure* the CPU frequency we set the
device to actually "takes". Along the way, I learned
if scaling_max_freq is < the frequency we set, the
scaling_max_freq will be used instead, which was
happening to the PixelCs and AndroidOnes.
As a result, this may make those two Test- configs faster.
Bug: skia:
Change-Id: I10c98d37e296a19e1cf67bfe7269bb59cdd912d5
Reviewed-on: https://skia-review.googlesource.com/74360
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Bug: skia:
Change-Id: I994f67c3043306d7fa612feb03f8fbe8d7bf4c91
Reviewed-on: https://skia-review.googlesource.com/73760
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
a.k.a. GM fontpocalypse
Change-Id: If834940574adea29b48f35abec61f0a1c9bd59d3
Reviewed-on: https://skia-review.googlesource.com/69881
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The first "sharding" technique we will try is just by test config
(e.g. 8888, gles, etc). Thus, for backwards compatibility,
the default "shard" is All, as in all configs
Bug: skia:
NOTRY=true
Change-Id: Ia02362477a5d97f8f74d688b5f0c4f45fc129375
Reviewed-on: https://skia-review.googlesource.com/59563
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
