New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 901466 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Dec 17
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

OOP-D M70 memory regression on stable channel compared to beta channel

Project Member Reported by kylec...@chromium.org, Nov 2

Issue description

There is an increase in renderer and total memory usage with OOP-D enabled with Window M70 stable compared to beta. The thing I'm comparing between stable and beta is the change (percentage) in memory used for experiment group compared to the control group.

Stable: https://uma.googleplex.com/p/chrome/variations/?sid=d2a5f7259d2fc192c1e9b5a5f4f6fb8e
Beta: https://uma.googleplex.com/p/chrome/variations/?sid=890edde1e4a48215e8a5f31c6b43956c

Memory.Total.PrivateMemoryFootprint on beta channel has a small regression at lower percentiles. This is expected (we're going to use a bit more command buffer memory) and matches perf bot results. The regression is probably still there at higher percentiles but it's smaller than variations due to noise. Beta channel matches what we've seen on canary and dev channels as well. Memory.Total.PrivateMemoryFootprint on stable channel has a consistent ~1.5% regression across all percentiles.

Memory.Renderer.PrivateMemoryFootprint on beta channel isn't changed. This is what we expect as OOP-D is essentially a no-op for the renderer. Beta channel again matches canary and dev channels. Memory.Renderer.PrivateMemoryFootprint on stable however shows a consistent regression which isn't expected at all. Nothing really changes as far as the renderer is concerned.

Memory.Total.RendererPrivateMemoryFootprint confirms what we saw in Memory.Renderer.PrivateMemoryFootprint. Beta channel shows no change and stable channel shows a consistent 1% regression.

Memory.Browser.PrivateMemoryFootprint improves (which is again expected) on both stable (-0.7%) and beta (-1.5%) channels. However, the improvement is more larger on beta channel, so stable channel is again using more memory.

Memory.Gpu.PrivateMemoryFootprint plus all the shared memory metrics look pretty similar between beta and stable.

So for some reason the renderer process and maybe browser process is using more memory with OOP-D enabled for Windows M70 stable channel compared to M70 beta channel.

Ideas for what could be causing this:
1. Differences in the population on each channel. Maybe there is something about beta/dev/canary users, eg. better average system specs, different usage patterns, different common extensions, etc.
2. Uptime difference between channels. If there was a slow memory leak and stable channel users had longer uptime they would have higher memory usage on average.
3. Intersection with another finch experiment. Maybe there is some finch experiment that decreases OOP-D group memory usage but not control group memory usage and that experiment isn't enabled on stable channel.

Adding a few GPU and memory people for ideas on how to better understand this.
 
The number of hits on Browser.PrivateMemoryFootprint is lower than the number on Gpu.PrivateMemoryFootprint. This is the case with both control and experiment group. I can't think of any reason why this would happen. Maybe we have multiple GPU processes?
Anyways comparing the counts on Gpu.PrivateMemoryFootprint, there is 5% more on experiment group. This might add to some skew in the comparison. But dashboard doesn't seem to complain. It might be because GPU process stays alive for longer because of reduced crash count, or hangs are more common and we start more GPU processes.

The increase in Total.RendererPrivateMemoryFootprint might also be related to the number of renderers. There seems to be increase in number of renderers consistently across all dates. If this experiment makes the user experience faster, then there is a chance that the users use more tabs. So, total renderer footprint might increase. The changes in individual renderer footprint is not significant.
> The number of hits on Browser.PrivateMemoryFootprint is lower than the number on Gpu.PrivateMemoryFootprint.

What filters/date/aggregation period were you looking at where you saw Memory.Gpu.PrivateMemoryFootprint counts being higher than Memory.Browser.PrivateMemoryFootprint counts? I see the opposite for the stable and beta links above, which is expected as sometimes the GPU process won't be running.

> The increase in Total.RendererPrivateMemoryFootprint might also be related to the number of renderers. There seems to be increase in number of renderers consistently across all dates. If this experiment makes the user experience faster, then there is a chance that the users use more tabs. So, total renderer footprint might increase. The changes in individual renderer footprint is not significant.

Interesting! I see that Memory.Total.RendererPrivateMemoryFootprint counts are higher for experiment vs control on stable but not on beta. Similarly Tabs.TabCount is higher for experiment vs control on stable but not on beta. That would explain a chunk of the extra memory usage at least. Were you looking at any other metrics for this?
Status: WontFix (was: Assigned)

Sign in to add a comment