Bug 187919 - Revert back to using phys_footprint to calculate isUnderMemoryPressure()
Summary: Revert back to using phys_footprint to calculate isUnderMemoryPressure()
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: bmalloc (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Saam Barati
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-07-23 13:19 PDT by Saam Barati
Modified: 2018-07-24 19:09 PDT (History)
17 users (show)

See Also:


Attachments
patch (4.86 KB, patch)
2018-07-23 17:43 PDT, Saam Barati
saam: review-
Details | Formatted Diff | Diff
patch (2.90 KB, patch)
2018-07-24 17:41 PDT, Saam Barati
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Saam Barati 2018-07-23 13:19:07 PDT
Currently, we rely on bmalloc's physicalFootprint calculation. However, bmalloc may have a small or mediumish heap, but the process may be using a lot of dirty memory from elsewhere. It could still be helpful in preventing jetsam if bmalloc freed stuff.
Comment 1 Saam Barati 2018-07-23 17:43:30 PDT
Created attachment 345630 [details]
patch
Comment 2 Simon Fraser (smfr) 2018-07-23 17:51:33 PDT
Comment on attachment 345630 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=345630&action=review

> Source/bmalloc/bmalloc/Scavenger.cpp:136
> +        task_vm_info_data_t vmInfo;
> +        mach_msg_type_number_t vmSize = TASK_VM_INFO_COUNT;
> +        if (KERN_SUCCESS == task_info(mach_task_self(), TASK_VM_INFO, (task_info_t)(&vmInfo), &vmSize))
> +            return static_cast<double>(vmInfo.phys_footprint);
> +        return 0.0;

Can this share code with memoryStatus()?

> Source/bmalloc/bmalloc/Scavenger.cpp:140
> +    if (osFootprint / hardwareMemoryCapacity > 0.9)
> +        return true;

I don't know how to reason whether that 90% threshold is reasonable. If feels bad to not scavenge if we're using 800MB, because 800MB is huge.
Comment 3 Saam Barati 2018-07-23 17:57:03 PDT
Comment on attachment 345630 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=345630&action=review

>> Source/bmalloc/bmalloc/Scavenger.cpp:136
>> +        return 0.0;
> 
> Can this share code with memoryStatus()?

Yeah I can make it shared

>> Source/bmalloc/bmalloc/Scavenger.cpp:140
>> +        return true;
> 
> I don't know how to reason whether that 90% threshold is reasonable. If feels bad to not scavenge if we're using 800MB, because 800MB is huge.

This is just a heuristic. But specifically in this case, 800/840 > .9
Comment 4 Joseph Pecoraro 2018-07-23 19:53:40 PDT
Comment on attachment 345630 [details]
patch

This looks good to me.
Comment 5 Geoffrey Garen 2018-07-24 10:12:00 PDT
The logic of this code is getting pretty complicated, with multiple authors and multiple constraints we're trying to solve for.

How do we know if we're making things better or worse?
Comment 6 Saam Barati 2018-07-24 11:39:10 PDT
(In reply to Geoffrey Garen from comment #5)
> The logic of this code is getting pretty complicated, with multiple authors
> and multiple constraints we're trying to solve for.
> 
> How do we know if we're making things better or worse?

When I implemented partial scavenging I manually verified we use less memory on average on the popular JS benchmarks.

For this change, I don’t know of a way to validate it besides just thinking about certain heap shapes that might lead bmalloc to not return memory to the OS.

Reasoning about this change, the only way I see it making things worse is by overscavenging when we’re close to the process’s memory limit. If that happens we’re in a world where we’re burning more CPU than necessary. However, it still seems better under that situation to spend CPU trying to free memory instead of allowing the process to jetsam
Comment 7 Radar WebKit Bug Importer 2018-07-24 13:04:48 PDT
<rdar://problem/42552888>
Comment 8 Saam Barati 2018-07-24 17:41:15 PDT
Created attachment 345731 [details]
patch
Comment 9 WebKit Commit Bot 2018-07-24 19:09:52 PDT
Comment on attachment 345731 [details]
patch

Clearing flags on attachment: 345731

Committed r234185: <https://trac.webkit.org/changeset/234185>
Comment 10 WebKit Commit Bot 2018-07-24 19:09:54 PDT
All reviewed patches have been landed.  Closing bug.