GLES ProgramCache listens to memory pressure

GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2921653005
Cr-Commit-Position: refs/heads/master@{#478080}
Committed: https://chromium.googlesource.com/chromium/src/+/49b5badc7cb27ac9e9c0f65ca6ce04a0b82800e2

[ssid, 2017-06-02 18:38:56]

Description was changed from

==========
GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
==========

to

==========
GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[ssid, 2017-06-02 19:31:05]

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

[commit-bot: I haz the power, 2017-06-02 19:31: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, 2017-06-02 19:34:50]

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

[commit-bot: I haz the power, 2017-06-02 19:34:51]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  mac_optional_gpu_tests_rel on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_optional_gpu_...)

[ssid, 2017-06-02 19:41:07]

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

[ssid, 2017-06-02 19:41:19]

Patchset #2 (id:20001) has been deleted

[commit-bot: I haz the power, 2017-06-02 19:41:56]

Dry run: CQ is trying da patch.

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

[ssid, 2017-06-02 20:29:07]

ssid@chromium.org changed reviewers:
+ vmiura@chromium.org

[ssid, 2017-06-02 20:29:07]

+Victor ptal, thanks!

[commit-bot: I haz the power, 2017-06-02 21:40:49]

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

[commit-bot: I haz the power, 2017-06-02 21:40:49]

Dry run: This issue passed the CQ dry run.

[vmiura, 2017-06-03 04:05:32]

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/comm...
File gpu/command_buffer/common/constants.h (right):

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/comm...
gpu/command_buffer/common/constants.h:77: const size_t
kDefaultMaxProgramCacheMemoryBytes = 512 * 1024;
Have we done any study of typical program cache usage?

I wonder if it would be worth using different limits if we're on low memory
Android vs default?

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/serv...
File gpu/command_buffer/service/memory_program_cache.cc (right):

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/serv...
gpu/command_buffer/service/memory_program_cache.cc:481: size_t limit =
max_size_bytes_ / 4;
nit: Could you add a comment why this is "max_size_bytes_ / 4", e.g. default for
MEMORY_PRESSURE_LEVEL_MODERATE.

[ssid, 2017-06-05 19:42:45]

thanks ptal

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/comm...
File gpu/command_buffer/common/constants.h (right):

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/comm...
gpu/command_buffer/common/constants.h:77: const size_t
kDefaultMaxProgramCacheMemoryBytes = 512 * 1024;
On 2017/06/03 04:05:31, vmiura wrote:
> Have we done any study of typical program cache usage?
> 
I looked at sizes of program cache on different websites and the sizes are in
range 4-10KiB. We could have tens of them in memory for each website.

> I wonder if it would be worth using different limits if we're on low memory
> Android vs default?

As I said earlier we never really hit the 512KB limit on a single website in
general cases on Phones. So, 512KB can hold shaders for about 5-7 last viewed
websites. So, I reduced the limit further for low-end devices.

Are there any specific cases that we might regress on, like a shader intensive
website maybe? I could try and see if this causes any issue.

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/serv...
File gpu/command_buffer/service/memory_program_cache.cc (right):

https://codereview.chromium.org/2921653005/diff/40001/gpu/command_buffer/serv...
gpu/command_buffer/service/memory_program_cache.cc:481: size_t limit =
max_size_bytes_ / 4;
On 2017/06/03 04:05:32, vmiura wrote:
> nit: Could you add a comment why this is "max_size_bytes_ / 4", e.g. default
for
> MEMORY_PRESSURE_LEVEL_MODERATE.

Added comment.

[vmiura, 2017-06-05 19:58:03]

vmiura@chromium.org changed reviewers:
+ ericrk@chromium.org, kbr@chromium.org

[vmiura, 2017-06-05 19:58:03]

+ericrk for thoughts on cache size.
+kbr for comment on sites with large numbers of shaders.

My concern for limiting the default cache on all Android devices is we will pay
some loading performance cost when re-visiting sites.  On low memory devices
trimming memory to a minimum seems to be a good trade-off.

I would also like to test what is the behavior when the DiskCache was 6MB and is
now reduced to 512KB.  Does the DiskCache get appropriately trimmed?

[ericrk, 2017-06-05 20:20:43]

On 2017/06/05 19:58:03, vmiura wrote:
> +ericrk for thoughts on cache size.
> +kbr for comment on sites with large numbers of shaders.
> 
> My concern for limiting the default cache on all Android devices is we will
pay
> some loading performance cost when re-visiting sites.  On low memory devices
> trimming memory to a minimum seems to be a good trade-off.
In addition to re-visiting sites, this may also impact subsequent (unrelated)
site loads, as a good number of shaders are re-used between unrelated sites.

I'm also curious how far we need to lower this on non-low-memory Android. Memory
program cache is a gpu proc singleton (one exists, on the channel manager). So
we don't have to worry about this limit multiplying. For non-low-memory android
we could drop the limit, but 512K seems pretty extreme.

Another thing to worry about is that, due to the way our telemetry tests work,
performance regressions from this change won't appear in most telemetry
scenarios. This is a bit concerning, as it makes it hard to know what the
performance impact is. We should watch UMA pretty carefully when we land this.

Overall, given the difficulty of getting good perf numbers for this change, I'd
want to be pretty careful before moving ahead. If we were to *only* tweak the
low-end-android value, I'd be less concerned, but either way it'd be good to:
- Run some common sites (top 25?) and see how much cache each site uses.
- Run some telemetry stories without browser restarts to measure the impact of
this change on subsequent site loads (I can help with the tweak, I've done this
before).

It may turn out that no real site uses close to 6MB, in which case lowering
seems fine, but I'd like to get more data before picking a number.

> 
> I would also like to test what is the behavior when the DiskCache was 6MB and
is
> now reduced to 512KB.  Does the DiskCache get appropriately trimmed?

[Ken Russell (switch to Gerrit), 2017-06-05 20:47:34]

Agree with Eric's analysis of this CL; it seems risky in terms of performance to
change this for all Android devices rather than just low-end ones. If this
change is to be made then more data needs to be gathered to demonstrate that
performance won't be impacted. A couple of targeted comments.

https://codereview.chromium.org/2921653005/diff/60001/gpu/command_buffer/comm...
File gpu/command_buffer/common/constants.h (right):

https://codereview.chromium.org/2921653005/diff/60001/gpu/command_buffer/comm...
gpu/command_buffer/common/constants.h:77: const size_t
kDefaultMaxProgramCacheMemoryBytes = 512 * 1024;
I agree with ericrk@'s comment that this may impact performance adversely on a
large number of Android devices. Please define this as a new constant for
low-memory devices.

https://codereview.chromium.org/2921653005/diff/60001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gpu_preferences.cc (right):

https://codereview.chromium.org/2921653005/diff/60001/gpu/command_buffer/serv...
gpu/command_buffer/service/gpu_preferences.cc:13: if
(base::SysInfo::IsLowEndDevice()) {
Please reference a different constant for low-end devices, rather than changing
the behavior for all Android devices.

[ssid, 2017-06-05 21:59:27]

As I mentioned earlier, the typical program binary size is 2-10KB and loading a
typical site creates 4-10 programs. Considering the extreme case of loading all
the popular sites that use high number of programs, we can hit the limit of
512KB after loading 10 sites.
I ran telemetry benchmark without browser shutdown and it turns out that the
maximum value of the cache size reached to 200KB after loading 25 sites and
scrolling.
I tested manually browsing for 15 minutes loading various common websites /
pages and I couldn't reach the 512KB limit.
So, in all these cases there should be no regression at all.

Considering the above, I do not understand why you feel that 512KB is pretty
extreme, even for high end devices. I cannot see how a 6MB limit can be reached
on Android.

There could be cases where we have high usage of shaders by some websites that I
have not considered and that is why I was asking for cases like such for testing
regression.

[ericrk, 2017-06-05 22:19:53]

On 2017/06/05 21:59:27, ssid wrote:
> As I mentioned earlier, the typical program binary size is 2-10KB and loading
a
> typical site creates 4-10 programs. Considering the extreme case of loading
all
> the popular sites that use high number of programs, we can hit the limit of
> 512KB after loading 10 sites.
> I ran telemetry benchmark without browser shutdown and it turns out that the
> maximum value of the cache size reached to 200KB after loading 25 sites and
> scrolling.
> I tested manually browsing for 15 minutes loading various common websites /
> pages and I couldn't reach the 512KB limit.
> So, in all these cases there should be no regression at all.
> 
> Considering the above, I do not understand why you feel that 512KB is pretty
> extreme, even for high end devices. I cannot see how a 6MB limit can be
reached
> on Android.
> 
> There could be cases where we have high usage of shaders by some websites that
I
> have not considered and that is why I was asking for cases like such for
testing
> regression.

Thanks for the additional testing! Sorry I missed your previous comment. This
makes me feel better about the values you've chosen.

I'm not personally aware of specific sites which will stress this more/less.
Maybe some WebGL games? kbr@, do you have any thoughts on this?

If we can't find an easy way to even breach the 512KB limit (even with multiple
sites and longish browsing sessions), then I think I'm OK with
this change. One last thing you might quickly check is whether different GL
Vendors (Adreno / Tegra / Mali) have very different shader binary sizes.

It would be nice to add an UMA to validate our beliefs... trying to think of one
that won't be too susceptible to noise (the disk cache makes something
simple like total size meaningless, as I imagine almost all users will
*eventually* hit 512K... although if they didn't that would really
indicate that this change had no downside :D). Maybe something like MB of cached
programs used over any 1 hour period? Have to think about this more.

[Ken Russell (switch to Gerrit), 2017-06-05 22:21:22]

Description was changed from

==========
GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Ken Russell (switch to Gerrit), 2017-06-05 22:21:53]

On 2017/06/05 21:59:27, ssid wrote:
> As I mentioned earlier, the typical program binary size is 2-10KB and loading
a
> typical site creates 4-10 programs. Considering the extreme case of loading
all
> the popular sites that use high number of programs, we can hit the limit of
> 512KB after loading 10 sites.
> I ran telemetry benchmark without browser shutdown and it turns out that the
> maximum value of the cache size reached to 200KB after loading 25 sites and
> scrolling.
> I tested manually browsing for 15 minutes loading various common websites /
> pages and I couldn't reach the 512KB limit.
> So, in all these cases there should be no regression at all.
> 
> Considering the above, I do not understand why you feel that 512KB is pretty
> extreme, even for high end devices. I cannot see how a 6MB limit can be
reached
> on Android.
> 
> There could be cases where we have high usage of shaders by some websites that
I
> have not considered and that is why I was asking for cases like such for
testing
> regression.

Please try maps.google.com, which is based on WebGL at this point. Please also
try:
  https://www.shadertoy.com/
  https://threejs.org/examples/
  After the Flood: https://playcanv.as/e/p/44MRmJRU/
  https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html

These are just a few examples of recent sites with moderate to heavy use of
shaders. Let's see how well these perform before coming up with more examples.

[vmiura, 2017-06-05 22:52:08]

On 2017/06/05 21:59:27, ssid wrote:
> As I mentioned earlier, the typical program binary size is 2-10KB and loading
a
> typical site creates 4-10 programs. Considering the extreme case of loading
all
> the popular sites that use high number of programs, we can hit the limit of
> 512KB after loading 10 sites.
> I ran telemetry benchmark without browser shutdown and it turns out that the
> maximum value of the cache size reached to 200KB after loading 25 sites and
> scrolling.
> I tested manually browsing for 15 minutes loading various common websites /
> pages and I couldn't reach the 512KB limit.
> So, in all these cases there should be no regression at all.

Could you confirm if GPU Rasterization was enabled?  For low-end Android that
is currently in a Finch trial.

[ssid, 2017-06-06 22:31:09]

> Thanks for the additional testing! Sorry I missed your previous comment. This
> makes me feel better about the values you've chosen.
> 
> I'm not personally aware of specific sites which will stress this more/less.
> Maybe some WebGL games? kbr@, do you have any thoughts on this?
> 
> If we can't find an easy way to even breach the 512KB limit (even with
multiple
> sites and longish browsing sessions), then I think I'm OK with
> this change. One last thing you might quickly check is whether different GL
> Vendors (Adreno / Tegra / Mali) have very different shader binary sizes.
> 

Good point. I checked on 3 other devices. Nexus 6p with Ardeno has higher
program sizes like 15-25KB and Android one and Nexus 7 does not seem to use the
program cache.
In 2 devices with mali driver, the program size is similar to what I mentioned
earlier.
Since this is varying a lot, I have taken some data from UMA.

> It would be nice to add an UMA to validate our beliefs... trying to think of
one
> that won't be too susceptible to noise (the disk cache makes something
> simple like total size meaningless, as I imagine almost all users will
> *eventually* hit 512K... although if they didn't that would really
> indicate that this change had no downside :D). Maybe something like MB of
cached
> programs used over any 1 hour period? Have to think about this more.

I found the UMA of the cache size vs program size:
https://uma.googleplex.com/p/chrome/histograms/?endDate=20170604&dayCount=1&h...

The median value of cache size on high end devices is 512KB. Low end devices is
40KB
Keeping the limit at 99th percentile values for both. 2MB and 512KB.

> Please try http://maps.google.com, which is based on WebGL at this point.
Please also
> try:
>   https://www.shadertoy.com/
>   https://threejs.org/examples/
>   After the Flood: https://playcanv.as/e/p/44MRmJRU/
>   https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html
> 
> These are just a few examples of recent sites with moderate to heavy use of
> shaders. Let's see how well these perform before coming up with more examples.

Thanks for the sites.
Maps does not seem to use much of shader cache memory. and some websites do not
work on mobile, like https://playcanv.as/e/p/44MRmJRU/.
Yes, these sites use a lot more shaders than the normal websites. I hit cases
where browsing across the same site causes eviction of cache if I set the limit
to 512KB. This does not seem very desirable.
I think even if they are extreme cases we want them to work well in high end
devices. So, I raised the limit for high end devices to 2MB on Android.


> Could you confirm if GPU Rasterization was enabled?  For low-end Android that
> is currently in a Finch trial.

I am testing on high end device. There seems to be no difference with
--enable-gpu-rasterization flag.

https://codereview.chromium.org/2921653005/diff/60001/gpu/command_buffer/serv...
File gpu/command_buffer/service/gpu_preferences.cc (right):

https://codereview.chromium.org/2921653005/diff/60001/gpu/command_buffer/serv...
gpu/command_buffer/service/gpu_preferences.cc:13: if
(base::SysInfo::IsLowEndDevice()) {
On 2017/06/05 20:47:34, Ken Russell wrote:
> Please reference a different constant for low-end devices, rather than
changing
> the behavior for all Android devices.

Done.

[ssid, 2017-06-06 22:31:45]

Patchset #5 (id:100001) has been deleted

[ssid, 2017-06-06 22:32:22]

Patchset #4 (id:80001) has been deleted

[Ken Russell (switch to Gerrit), 2017-06-06 22:41:54]

Thanks for doing these measurements and updating the constants for Android. LGTM
from my standpoint. I'm not an OWNER of these files though.

[Kai Ninomiya, 2017-06-06 22:47:12]

kainino@chromium.org changed reviewers:
+ kainino@chromium.org

[Kai Ninomiya, 2017-06-06 22:47:13]

FYI, the playcanvas demo should work fine if you use 'Request desktop site'.

[Kai Ninomiya, 2017-06-06 22:49:03]

On 2017/06/06 22:47:13, Kai Ninomiya wrote:
> FYI, the playcanvas demo should work fine if you use 'Request desktop site'.

(er, assuming it doesn't run out of GPU memory, which does happen pretty
frequently)

[ssid, 2017-06-06 23:17:47]

On 2017/06/06 22:49:03, Kai Ninomiya wrote:
> On 2017/06/06 22:47:13, Kai Ninomiya wrote:
> > FYI, the playcanvas demo should work fine if you use 'Request desktop site'.
> 
> (er, assuming it doesn't run out of GPU memory, which does happen pretty
> frequently)

Yes I did try with use desktop site. It loads 50% of the times and I can't tell
if this change makes it any slower.
But this site could use around 6MB of shaders too.

[ssid, 2017-06-08 00:20:52]

ping vmiura@

[vmiura, 2017-06-08 00:38:19]

On 2017/06/08 00:20:52, ssid wrote:
> ping vmiura@

lgtm, thanks!

[ssid, 2017-06-08 01:06:50]

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

[commit-bot: I haz the power, 2017-06-08 01:07:12]

Dry run: CQ is trying da patch.

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

[ssid, 2017-06-08 01:07:48]

ssid@chromium.org changed reviewers:
+ isherman@chromium.org

[ssid, 2017-06-08 01:07:49]

+ilya for histograms.xml.
ptal thanks!

[Ilya Sherman, 2017-06-08 01:11:38]

Metrics LGTM

https://codereview.chromium.org/2921653005/diff/120001/gpu/command_buffer/ser...
File gpu/command_buffer/service/memory_program_cache.cc (right):

https://codereview.chromium.org/2921653005/diff/120001/gpu/command_buffer/ser...
gpu/command_buffer/service/memory_program_cache.cc:492:
base::UmaHistogramCounts100000("GPU.ProgramCache.MemoryReleasedOnPressure",
Optional nit: It's slightly more efficient to use the macro version,
UMA_HISTOGRAM_COUNTS_100000, when the histogram name is a constant.

[ssid, 2017-06-08 01:18:17]

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

[commit-bot: I haz the power, 2017-06-08 01:18:33]

Dry run: CQ is trying da patch.

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

[ssid, 2017-06-08 01:18:44]

fixed, thanks

https://codereview.chromium.org/2921653005/diff/120001/gpu/command_buffer/ser...
File gpu/command_buffer/service/memory_program_cache.cc (right):

https://codereview.chromium.org/2921653005/diff/120001/gpu/command_buffer/ser...
gpu/command_buffer/service/memory_program_cache.cc:492:
base::UmaHistogramCounts100000("GPU.ProgramCache.MemoryReleasedOnPressure",
On 2017/06/08 01:11:38, Ilya Sherman wrote:
> Optional nit: It's slightly more efficient to use the macro version,
> UMA_HISTOGRAM_COUNTS_100000, when the histogram name is a constant.

Ah yes. Thanks! I should remember when to use the macros.

[commit-bot: I haz the power, 2017-06-08 01:39:07]

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

[commit-bot: I haz the power, 2017-06-08 01:39:09]

Dry run: Try jobs failed on following builders:
  linux_chromium_headless_rel on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[ssid, 2017-06-08 01:45:04]

ssid@chromium.org changed reviewers:
+ altimin@chromium.org, skyostil@chromium.org

[ssid, 2017-06-08 01:45:05]

+Alexander and Sami. This CL is failing the headless bot because of not being
able to call AmountOfPhysicalMemory() method. Can you please help out with this?

[Sami, 2017-06-08 16:20:56]

On 2017/06/08 01:45:05, ssid wrote:
> +Alexander and Sami. This CL is failing the headless bot because of not being
> able to call AmountOfPhysicalMemory() method. Can you please help out with
this?

That's really bizarre. Headless shouldn't really affect how sysconf() works. I
tried to reproduce this failure locally and couldn't :\

[ssid, 2017-06-08 18:35:12]

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

[commit-bot: I haz the power, 2017-06-08 18:36:00]

Dry run: CQ is trying da patch.

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

[ssid, 2017-06-08 19:17:28]

On 2017/06/08 16:20:56, Sami wrote:
> On 2017/06/08 01:45:05, ssid wrote:
> > +Alexander and Sami. This CL is failing the headless bot because of not
being
> > able to call AmountOfPhysicalMemory() method. Can you please help out with
> this?
> 
> That's really bizarre. Headless shouldn't really affect how sysconf() works. I
> tried to reproduce this failure locally and couldn't :\

Okay figured that glib implementation of sysconf just tries to read
"/proc/meminfo". open() is not allowed by sandbox on linux child processes. It
seems like a battle to fight to change the way sys_info works or change the
sandbox whitelist. So, I am just going to go with ifdef before calling
IsLowEndDevice using it only on Android.

[commit-bot: I haz the power, 2017-06-08 20:07:04]

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

[commit-bot: I haz the power, 2017-06-08 20:07:05]

Dry run: This issue passed the CQ dry run.

[ssid, 2017-06-08 20:43:50]

The CQ bit was checked by ssid@chromium.org

[ssid, 2017-06-08 20:43:50]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
isherman@chromium.org, vmiura@chromium.org
Link to the patchset: https://codereview.chromium.org/2921653005/#ps160001
(title: "low-end check only on Android.")

[commit-bot: I haz the power, 2017-06-08 20:44:19]

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, 2017-06-08 20:49:43]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1496954630235060,
"parent_rev": "8bf6a78c50c5e34780dd5e9713c6d86134bbc265", "commit_rev":
"49b5badc7cb27ac9e9c0f65ca6ce04a0b82800e2"}

[commit-bot: I haz the power, 2017-06-08 20:49:58]

Description was changed from

==========
GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
GLES ProgramCache listens to memory pressure

Change the size limit of gl program cache for android and clear the
cache on memory pressure situations.

BUG=725303
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2921653005
Cr-Commit-Position: refs/heads/master@{#478080}
Committed:
https://chromium.googlesource.com/chromium/src/+/49b5badc7cb27ac9e9c0f65ca6ce...
==========

[commit-bot: I haz the power, 2017-06-08 20:50:00]

Committed patchset #6 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/49b5badc7cb27ac9e9c0f65ca6ce...