[ProcessPerSite] Add PrivateMemoryFootprint heuristic [chromium/src : main]

0 views
Skip to first unread message

gwsq (Gerrit)

unread,
Jul 12, 2024, 11:43:19 AM (5 days ago) Jul 12
to Dave Tapuska, AyeAye, Code Review Nudger, James Maclean, Alex Moshchuk, Charlie Reis, Tricium, Chromium LUCI CQ, chromium...@chromium.org, blundell+...@chromium.org, mac-r...@chromium.org, chrome-gr...@chromium.org, alexmo...@chromium.org, creis...@chromium.org, navigation...@chromium.org
Attention needed from Alex Moshchuk, Charlie Reis and James Maclean

Message from gwsq

Warning: gwsq did not assign any reviewers.

Open in Gerrit

Related details

Attention is currently required from:
  • Alex Moshchuk
  • Charlie Reis
  • James Maclean
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedNo-Unresolved-Comments
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: Ia6d17d9e8bf0246a37cc5c16065069fe82e564a5
Gerrit-Change-Number: 5642354
Gerrit-PatchSet: 7
Gerrit-Owner: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: Alex Moshchuk <ale...@chromium.org>
Gerrit-Reviewer: Charlie Reis <cr...@chromium.org>
Gerrit-Reviewer: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: James Maclean <wjma...@chromium.org>
Gerrit-CC: Code Review Nudger <android-build...@prod.google.com>
Gerrit-CC: gwsq
Gerrit-Attention: Charlie Reis <cr...@chromium.org>
Gerrit-Attention: James Maclean <wjma...@chromium.org>
Gerrit-Attention: Alex Moshchuk <ale...@chromium.org>
Gerrit-Comment-Date: Fri, 12 Jul 2024 15:43:09 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
satisfied_requirement
unsatisfied_requirement
open
diffy

gwsq (Gerrit)

unread,
Jul 12, 2024, 11:54:18 AM (5 days ago) Jul 12
to Dave Tapuska, AyeAye, Code Review Nudger, James Maclean, Alex Moshchuk, Charlie Reis, Tricium, Chromium LUCI CQ, chromium...@chromium.org, blundell+...@chromium.org, mac-r...@chromium.org, chrome-gr...@chromium.org, alexmo...@chromium.org, creis...@chromium.org, navigation...@chromium.org
Attention needed from Alex Moshchuk, Charlie Reis, Dave Tapuska and James Maclean

Message from gwsq

Warning: gwsq did not assign any reviewers.

Open in Gerrit

Related details

Attention is currently required from:
  • Alex Moshchuk
  • Charlie Reis
  • Dave Tapuska
  • James Maclean
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedNo-Unresolved-Comments
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: Ia6d17d9e8bf0246a37cc5c16065069fe82e564a5
Gerrit-Change-Number: 5642354
Gerrit-PatchSet: 7
Gerrit-Owner: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: Alex Moshchuk <ale...@chromium.org>
Gerrit-Reviewer: Charlie Reis <cr...@chromium.org>
Gerrit-Reviewer: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: James Maclean <wjma...@chromium.org>
Gerrit-CC: Code Review Nudger <android-build...@prod.google.com>
Gerrit-CC: gwsq
Gerrit-Attention: Dave Tapuska <dtap...@chromium.org>
Gerrit-Attention: Charlie Reis <cr...@chromium.org>
Gerrit-Attention: James Maclean <wjma...@chromium.org>
Gerrit-Attention: Alex Moshchuk <ale...@chromium.org>
Gerrit-Comment-Date: Fri, 12 Jul 2024 15:54:05 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
satisfied_requirement
unsatisfied_requirement
open
diffy

Charlie Reis (Gerrit)

unread,
Jul 12, 2024, 12:24:50 PM (5 days ago) Jul 12
to Dave Tapuska, AyeAye, Code Review Nudger, James Maclean, Alex Moshchuk, Tricium, Chromium LUCI CQ, chromium...@chromium.org, blundell+...@chromium.org, mac-r...@chromium.org, chrome-gr...@chromium.org, alexmo...@chromium.org, creis...@chromium.org, navigation...@chromium.org
Attention needed from Alex Moshchuk, Dave Tapuska and James Maclean

Charlie Reis added 10 comments

Patchset-level comments
File-level comment, Patchset 8 (Latest):
Charlie Reis . resolved

Thanks. Sending a few replies now since I'm in the attention set (before I go OOO), though it looks like it's still failing some try jobs and there are still some unresolved comments.

Commit Message
Line 10, Patchset 4:the average size of a tab within an upper limit being reached.
Charlie Reis . unresolved

Can you elaborate to be more precise here? I'm unclear what you mean by "average size of a tab," especially since a tab might have OOPIFs that live in a different process, and since the average size of a main frame in general can vary significantly.

Is this trying to estimate how much memory is being used by each top-level page currently in the process (including any in-process subframes in those pages)?

Charlie Reis

Friendly ping on this, because it will help me understand the goals for the algorithm you're writing.

File content/browser/renderer_host/render_process_host_impl.h
Line 1500, Patchset 7: uint64_t private_memory_footprint_bytes_ = 0u;
Charlie Reis . unresolved

This looks the same on both sides of the ifdef. Can it be pulled out?

File content/browser/renderer_host/render_process_host_impl.cc
Line 519, Patchset 7: // of another main frame into the memory space.
Charlie Reis . unresolved

I think it would be useful to provide more of an overview of what we're trying to compute here, similar to my question in the CL description. (There's a lot of ways this could be done, so it's worth laying out what we're trying to check, such as what we're assuming about the size of a main frame and what we're assuming the "memory space" is.)

Line 548, Patchset 7: // Only log the histogram once, we don't want to over-record.
Charlie Reis . unresolved

Once per what? It looks like context matters here, and that we're logging this only the first time that a process is *not* reused? That might be reasonable, but I'm trying to understand what the metric will mean-- it won't show if a process is later reused (e.g., if the size went down) or if the size continues to go up, but maybe that's ok? I suppose it's mostly painting a picture of where the cutoff is in practice?

(Also, does this metric need to be documented in an xml file?)

Line 620, Patchset 4: auto* host = static_cast<RenderProcessHostImpl*>(
Charlie Reis . resolved

Per Alex's earlier note, this looks like it's probably called from within unit tests, so I'm not sure whether this cast is safe. (If it is, we should include a comment explaining why.)

Charlie Reis

Done

Line 4912, Patchset 4: bool success = memory_instrumentation::OSMetrics::FillOSMemoryDump(
Alex Moshchuk . unresolved

Curious if this is fast enough to be called on potentially several processes, on a path where a slowdown would affect start-to-commit times for navigations?

Dave Tapuska

On my linux machine this is 300-400 microseconds, I haven't tried on other OSes yet, but hopefully it is similar. But I agree using a cache for a short period is likely best.

Charlie Reis

300-400 milliseconds sounds like a significant slowdown, right? This is called via MayReuseAndIsSuitableWithMainFrameThreshold and thus in a fairly critical path during navigation via GetProcessHostForSiteInstance. Is there a way to tell what impact this is having on navigation latency when it does get called, even if it gets cached for 20 seconds? (That will help us decide if we have to do something more clever or not.)

Line 4927, Patchset 7: constexpr base::TimeDelta kPrimateMemoryFootprintCacheValidTime =
Charlie Reis . unresolved

Private?

Line 4932, Patchset 7: return private_memory_footprint_bytes_;
Charlie Reis . unresolved

I don't see this value getting updated below when we actually compute it in the non-cached case. Did I miss that part?

File services/resource_coordinator/public/cpp/memory_instrumentation/os_metrics_mac.cc
Line 256, Patchset 7: }
Charlie Reis . unresolved

Can you help me understand why we need these changes to the platform-specific FillOSMemoryDump code?

Open in Gerrit

Related details

Attention is currently required from:
  • Alex Moshchuk
  • Dave Tapuska
  • James Maclean
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedNo-Unresolved-Comments
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: Ia6d17d9e8bf0246a37cc5c16065069fe82e564a5
Gerrit-Change-Number: 5642354
Gerrit-PatchSet: 8
Gerrit-Owner: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: Alex Moshchuk <ale...@chromium.org>
Gerrit-Reviewer: Charlie Reis <cr...@chromium.org>
Gerrit-Reviewer: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: James Maclean <wjma...@chromium.org>
Gerrit-CC: Code Review Nudger <android-build...@prod.google.com>
Gerrit-CC: gwsq
Gerrit-Attention: Dave Tapuska <dtap...@chromium.org>
Gerrit-Attention: James Maclean <wjma...@chromium.org>
Gerrit-Attention: Alex Moshchuk <ale...@chromium.org>
Gerrit-Comment-Date: Fri, 12 Jul 2024 16:24:40 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Dave Tapuska <dtap...@chromium.org>
Comment-In-Reply-To: Charlie Reis <cr...@chromium.org>
Comment-In-Reply-To: Alex Moshchuk <ale...@chromium.org>
satisfied_requirement
unsatisfied_requirement
open
diffy

Charlie Reis (Gerrit)

unread,
Jul 12, 2024, 12:29:52 PM (5 days ago) Jul 12
to Dave Tapuska, AyeAye, Code Review Nudger, James Maclean, Alex Moshchuk, Tricium, Chromium LUCI CQ, chromium...@chromium.org, blundell+...@chromium.org, mac-r...@chromium.org, chrome-gr...@chromium.org, alexmo...@chromium.org, creis...@chromium.org, navigation...@chromium.org
Attention needed from Alex Moshchuk, Dave Tapuska and James Maclean

Charlie Reis added 1 comment

File content/browser/renderer_host/render_process_host_impl.cc
Line 4912, Patchset 4: bool success = memory_instrumentation::OSMetrics::FillOSMemoryDump(
Alex Moshchuk . resolved

Curious if this is fast enough to be called on potentially several processes, on a path where a slowdown would affect start-to-commit times for navigations?

Dave Tapuska

On my linux machine this is 300-400 microseconds, I haven't tried on other OSes yet, but hopefully it is similar. But I agree using a cache for a short period is likely best.

Charlie Reis

300-400 milliseconds sounds like a significant slowdown, right? This is called via MayReuseAndIsSuitableWithMainFrameThreshold and thus in a fairly critical path during navigation via GetProcessHostForSiteInstance. Is there a way to tell what impact this is having on navigation latency when it does get called, even if it gets cached for 20 seconds? (That will help us decide if we have to do something more clever or not.)

Charlie Reis

Oh! Sorry, for misreading microseconds as milliseconds. That's much less of a concern.

Gerrit-Comment-Date: Fri, 12 Jul 2024 16:29:41 +0000
satisfied_requirement
unsatisfied_requirement
open
diffy

Dave Tapuska (Gerrit)

unread,
Jul 16, 2024, 12:20:56 PM (yesterday) Jul 16
to Chromium Metrics Reviews, AyeAye, Code Review Nudger, James Maclean, Alex Moshchuk, Charlie Reis, Tricium, Chromium LUCI CQ, chromium...@chromium.org, asvitkine...@chromium.org, blundell+...@chromium.org, mac-r...@chromium.org, chrome-gr...@chromium.org, alexmo...@chromium.org, creis...@chromium.org, navigation...@chromium.org
Attention needed from Alex Moshchuk, Charlie Reis and James Maclean

Dave Tapuska added 7 comments

Commit Message
Line 10, Patchset 4:the average size of a tab within an upper limit being reached.
Charlie Reis . resolved

Can you elaborate to be more precise here? I'm unclear what you mean by "average size of a tab," especially since a tab might have OOPIFs that live in a different process, and since the average size of a main frame in general can vary significantly.

Is this trying to estimate how much memory is being used by each top-level page currently in the process (including any in-process subframes in those pages)?

Charlie Reis

Friendly ping on this, because it will help me understand the goals for the algorithm you're writing.

Dave Tapuska

Done

Line 14, Patchset 4:Bug: 348199030
Charlie Reis . resolved

Is this also related to https://crbug.com/40259123, for a more general threshold that isn't specific to ProcessPerSite mode? Would this change work for that case as well, or would we need a separate threshold for when we're over the process limit?

Dave Tapuska

While this lays some ground work for that. I think trying to attribute the cost of OOPIFs would need some additional work.

File content/browser/renderer_host/render_process_host_impl.h
Line 1500, Patchset 7: uint64_t private_memory_footprint_bytes_ = 0u;
Charlie Reis . resolved

This looks the same on both sides of the ifdef. Can it be pulled out?

Dave Tapuska

I had debated naming this as cached_private_memory_footprint_bytes_ when I originally wrote it. But I've added comments to not use it directly.

File content/browser/renderer_host/render_process_host_impl.cc
Line 519, Patchset 7: // of another main frame into the memory space.
Charlie Reis . resolved

I think it would be useful to provide more of an overview of what we're trying to compute here, similar to my question in the CL description. (There's a lot of ways this could be done, so it's worth laying out what we're trying to check, such as what we're assuming about the size of a main frame and what we're assuming the "memory space" is.)

Dave Tapuska

Done

Line 548, Patchset 7: // Only log the histogram once, we don't want to over-record.
Charlie Reis . resolved

Once per what? It looks like context matters here, and that we're logging this only the first time that a process is *not* reused? That might be reasonable, but I'm trying to understand what the metric will mean-- it won't show if a process is later reused (e.g., if the size went down) or if the size continues to go up, but maybe that's ok? I suppose it's mostly painting a picture of where the cutoff is in practice?

(Also, does this metric need to be documented in an xml file?)

Dave Tapuska

Done

Line 4927, Patchset 7: constexpr base::TimeDelta kPrimateMemoryFootprintCacheValidTime =
Charlie Reis . resolved

Private?

Dave Tapuska

Done

Line 4932, Patchset 7: return private_memory_footprint_bytes_;
Charlie Reis . resolved

I don't see this value getting updated below when we actually compute it in the non-cached case. Did I miss that part?

Dave Tapuska

No it got dropped when I rewrote the Apple and windows ports. Fixed.

Open in Gerrit

Related details

Attention is currently required from:
  • Alex Moshchuk
  • Charlie Reis
  • James Maclean
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Review
  • requirement is not satisfiedNo-Unresolved-Comments
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: Ia6d17d9e8bf0246a37cc5c16065069fe82e564a5
Gerrit-Change-Number: 5642354
Gerrit-PatchSet: 13
Gerrit-Owner: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: Alex Moshchuk <ale...@chromium.org>
Gerrit-Reviewer: Charlie Reis <cr...@chromium.org>
Gerrit-Reviewer: Dave Tapuska <dtap...@chromium.org>
Gerrit-Reviewer: James Maclean <wjma...@chromium.org>
Gerrit-CC: Chromium Metrics Reviews <chromium-met...@google.com>
Gerrit-CC: Code Review Nudger <android-build...@prod.google.com>
Gerrit-CC: gwsq
Gerrit-Attention: Charlie Reis <cr...@chromium.org>
Gerrit-Attention: James Maclean <wjma...@chromium.org>
Gerrit-Attention: Alex Moshchuk <ale...@chromium.org>
Gerrit-Comment-Date: Tue, 16 Jul 2024 16:20:46 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Charlie Reis <cr...@chromium.org>
satisfied_requirement
unsatisfied_requirement
open
diffy

Dave Tapuska (Gerrit)

unread,
Jul 16, 2024, 12:21:37 PM (yesterday) Jul 16
to Chromium Metrics Reviews, AyeAye, Code Review Nudger, James Maclean, Alex Moshchuk, Charlie Reis, Tricium, Chromium LUCI CQ, chromium...@chromium.org, asvitkine...@chromium.org, blundell+...@chromium.org, mac-r...@chromium.org, chrome-gr...@chromium.org, alexmo...@chromium.org, creis...@chromium.org, navigation...@chromium.org
Attention needed from Alex Moshchuk, Charlie Reis and James Maclean

Dave Tapuska added 1 comment

File services/resource_coordinator/public/cpp/memory_instrumentation/os_metrics_mac.cc
Line 256, Patchset 7: }
Charlie Reis . resolved

Can you help me understand why we need these changes to the platform-specific FillOSMemoryDump code?

Dave Tapuska

Removed

Gerrit-Comment-Date: Tue, 16 Jul 2024 16:21:25 +0000
satisfied_requirement
unsatisfied_requirement
open
diffy
Reply all
Reply to author
Forward
0 new messages