This is mostly due to the large 4.2MB Skia Glyph cache texture - going to look into reducing the size of this on Svelte (currently 2048x2048x8bpp). Given the smaller screen size, we can probably drop to 1024x1024, which will take 3MB off.

Will put together a CL today.

Why did this not exist in previous version?

You're probably hitting the GPU rasterization finch trial? That was enabled for M59. Overall memory looked good (on system_health.memory_mobile, across all sites), but it's possible that there are individual site regressions that we should look more closely at.

I'd like to say that I had disabled all the finch trials while running the benchmark (excluded the "fieldtrial" command line flag. But, I am not sure that is the only way to hit the trials. Yes I did not find this particular regression on the benchmark graphs (also could have missed it because there were too many regressions in the graphs).

Also, do you have results from running the rasterization trial on telemetry benchmarks and confident that we do not regress on these stories (before enabling to the users)?

Actually, is this on svelte? Or on full Android?

Sorry forgot to mention, this is scale svelte 512MB device

Ok, then my guess as to why we regressed above still stands :D

Here's a document that outlines the testing I did - it includes summaries of system_health.memory_mobile as well as links to more detailed results: https://docs.google.com/document/d/1O2ksNEUR-LNoaVkEEbauoHpu-LeSN5qaQtJdKKiBn6w/edit

ping on this one.

CL is in progress - https://skia-review.googlesource.com/c/15135/

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/6d342285a4546b54cb17570aae7eeb8a123c81ae

commit 6d342285a4546b54cb17570aae7eeb8a123c81ae
Author: Eric Karl <ericrk@chromium.org>
Date: Fri May 05 21:07:51 2017

Allow custom GrAtlasGlyphCache texture sizes

A single glyph cache size doesn't make sense across the hardware Skia
runs on. This change allows a custom size to be specified (via a byte
limit), allowing cache size to be customized at context creation time.

Bug:  717178 
Change-Id: I4f7baddd1897b2eac4f6d6e4fff1f805e1cdd250
Reviewed-on: https://skia-review.googlesource.com/15135
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>

[modify] https://crrev.com/6d342285a4546b54cb17570aae7eeb8a123c81ae/src/gpu/GrContext.cpp
[modify] https://crrev.com/6d342285a4546b54cb17570aae7eeb8a123c81ae/include/gpu/GrContextOptions.h
[modify] https://crrev.com/6d342285a4546b54cb17570aae7eeb8a123c81ae/src/gpu/text/GrAtlasGlyphCache.h
[modify] https://crrev.com/6d342285a4546b54cb17570aae7eeb8a123c81ae/src/gpu/text/GrAtlasGlyphCache.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ce0013f7cb1f236cffbbae7bf43a6b7a8d09ef0

commit 9ce0013f7cb1f236cffbbae7bf43a6b7a8d09ef0
Author: ericrk <ericrk@chromium.org>
Date: Mon May 08 17:01:37 2017

Cause Skia to use a smaller glyph cache on low-end Android

Currently Skia uses an up-to 8MB/texture glyph cache on all Android
devices. To save memory on low-end devices we are switching to an
up-to 2MB cache.

BUG= 717178 
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/2869443003
Cr-Commit-Position: refs/heads/master@{#470022}

[modify] https://crrev.com/9ce0013f7cb1f236cffbbae7bf43a6b7a8d09ef0/gpu/skia_bindings/grcontext_for_gles2_interface.cc

Is this fixed?

Sorry for the delay. We've gotten this particular regression down from 3MB to 1MB, but it hasn't been totally eliminated.

It was expected that some sub-categories would regress with GPU raster, but others would improve, so this doesn't worry me too much. Overall this should have been ~even.

To give one example, in the original trace, we have 6MB of locked discardable memory, while in the later trace (where GPU memory regresses) we have 0MB of locked discardable.

Closing this out, as I think we're in a pretty good place.