https://bugs.webkit.org/show_bug.cgi?id=184684
Bug ID: 184684
Summary: [bmalloc][Linux] Implement isUnderMemoryPressure()
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: bmalloc
Assignee: webkit-unassigned at lists.webkit.org
Reporter: zan at falconsigh.net
CC: aperez at igalia.com, bugs-noreply at webkitgtk.org,
cgarcia at igalia.com, clopez at igalia.com,
eocanha at igalia.com, ggaren at apple.com,
mcatanzaro at igalia.com, pnormand at igalia.com,
utatane.tea at gmail.com
We're lacking an implementation of isUnderMemoryPressure() in bmalloc on Linux, which would help a lot with the scavenging process in memory-constrained systems. When found to be under memory pressure, the Scavenger thread makes an extra effort to free as much mapped memory as possible.
https://trac.webkit.org/browser/webkit/trunk/Source/bmalloc/bmalloc/AvailableMemory.h#L62
Calling back to bug #176089, one issue there was large memory consumption. While the fix in that bug helped a lot in that regard, always returning true in isUnderMemoryPressure() for testing purposes helps even further, keeping memory consumption of the WebProcess constantly well under 200MB, while otherwise it rises up to 300MB before it's finally scavenged down to a bit above 200MB.
There are other use cases that would benefit from correctly determining in bmalloc when the process is in a memory pressure situation. MSE requires multible MBs of data being constantly downloaded and fed into the media pipeline. This is reflected in memory consumption, where lack of scavenges causes that consumption to grow as the playback proceeds.
No clear idea how to implement this from my side. I suppose it could mimic memory pressure handler in WTF, but it might also depend on other things, e.g.whether GLib should be used in bmalloc.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180417/9e60b214/attachment.html>