New issue
Advanced search Search tips

Issue 757936 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature



Sign in to add a comment

Windows tab discarding: kLargeMemoryDefaultModerateThresholdMb and kLargeMemoryDefaultCriticalThresholdMb not aggressive enough!

Reported by test35...@gmail.com, Aug 22 2017

Issue description

UserAgent: Mozilla/5.0 (Linux; Android 7.1.2; Nexus 6P Build/N2G48B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3185.0 Mobile Safari/537.36

Steps to reproduce the problem:

1. Enable automatic tab discarding (which is awesome)
2. Open enough tabs on a large memory machine (8GB in this case) to make windows page furiously
3. Open task manager, see windows maintaining more "available memory" than will trigger actual discards (IIRC 400MB) while paging furiously.

What is the expected behavior?
Chrome should begin killing processes before the system slows to a crawl.

What went wrong?
The system slows to a crawl. 

Did this work before? No 

Chrome version: 60.0.3112.101  Channel: stable
OS Version: 7, SP1
Flash Version: 

I suspect that Windows begins paging at higher memory availability when running on systems with larger memory. Thus, kLargeMemoryDefaultCriticalThresholdMb is too small for real world use.
 
Labels: Needs-Triage-M60 Performance-Memory
Labels: -Needs-Triage-M60
Status: Untriaged (was: Unconfirmed)
Labels: Hotlist-GRC
Owner: chrisha@chromium.org
Assigning to chrisha for initial triage.
Status: WontFix (was: Untriaged)
These heuristics are very primitive, and not able to finely tuned. From observing machines in a lab it becomes pretty apparent that the memory manager tries to maintain a constant size free list, and swap aggressively to do so. We chose these thresholds based on the bulk of those observations.

We know that the threshold is too conservative in some cases, but we don't understand the entire logic of the memory manager, and exactly how it calculates a target free list.

Two things are happening here that will address this:

- We're trying to build a better heuristic based on observation of actual swapping conditions on an individual machine.
- We're making discarding much more aggressive and common place, making it far less likely that swapping will occur in the first place.

Thus this specific bug is a WontFix. We won't be investing any time trying to tune what is a known broken heuristic.

Sign in to add a comment