Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cc] Simplify and adjust memory limits on Android #4636

Merged
merged 1 commit into from
Jan 3, 2025

Conversation

borongc
Copy link
Contributor

@borongc borongc commented Jan 3, 2025

On Android, compositor memory limits are derived from system memory and
dalvik memory limits. This code was noted as outdated in 2017 (see
linked bug), and as a result didn't work the way it should have.

This is because:

  • Reported system RAM on Android is lower than installed RAM because of
    carveouts
  • Dalvik memory limits are not really correlated with system RAM

Based on field data, the large majority of devices is running with a
computed limit of 256MiB, with some devices using 96MiB. This CL
simplifies the code to:

  • Low-end or <2GiB: 96MiB
  • Otherwise, 256MiB

Which mostly matches the current in-the-wild reality. These limits are
likely not optimal, but at least this simplifies the code. Also, lower
the priority cutoff to "NICE_TO_HAVE", which matches desktop, and
reality, since ALLOW_EVERYTHING is lowered to NICE_TO_HAVE elsewhere in
the code (see PriorityCutoffToTileMemoryLimitPolicy() for instance).

This is gated behind a feature flag, to make sure that this is not
breaking things.

This change is backported from m120+.

(cherry picked from commit 42b97eaa9deace1c188434ccac37ee22223ade4f)

Bug: 380310632
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4860245

@borongc borongc requested a review from a team as a code owner January 3, 2025 01:25
@borongc borongc requested review from kaidokert and johnxwork January 3, 2025 01:28
On Android, compositor memory limits are derived from system memory and
dalvik memory limits. This code was noted as outdated in 2017 (see
linked bug), and as a result didn't work the way it should have.

This is because:
- Reported system RAM on Android is lower than installed RAM because of
  carveouts
- Dalvik memory limits are not really correlated with system RAM

Based on field data, the large majority of devices is running with a
computed limit of 256MiB, with some devices using 96MiB. This CL
simplifies the code to:
- Low-end or <2GiB: 96MiB
- Otherwise, 256MiB

Which mostly matches the current in-the-wild reality. These limits are
likely not optimal, but at least this simplifies the code. Also, lower
the priority cutoff to "NICE_TO_HAVE", which matches desktop, and
reality, since ALLOW_EVERYTHING is lowered to NICE_TO_HAVE elsewhere in
the code (see PriorityCutoffToTileMemoryLimitPolicy() for instance).

This is gated behind a feature flag, to make sure that this is not
breaking things.

(cherry picked from commit 42b97eaa9deace1c188434ccac37ee22223ade4f)

Bug: 380310632
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4860245
@borongc borongc merged commit 5e524cf into youtube:main Jan 3, 2025
66 of 67 checks passed
@borongc borongc deleted the cobalt_low_memory branch January 3, 2025 10:39
borongc added a commit that referenced this pull request Jan 6, 2025
1. Enable low end device mode to reduce memory usage.
2. The rendering issue was due to the memory limits in Blink, which is
resolved in m126+, where two upstream commits
(#4636,
#4637) were cherry picked.

b/380310632
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants