[Webkit-unassigned] [Bug 140062] New: [Linux] SeccompBroker processes use too much memory
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sun Jan 4 18:01:44 PST 2015
https://bugs.webkit.org/show_bug.cgi?id=140062
Bug ID: 140062
Summary: [Linux] SeccompBroker processes use too much memory
Classification: Unclassified
Product: WebKit
Version: 528+ (Nightly build)
Hardware: PC
OS: Linux
Status: NEW
Severity: Minor
Priority: P2
Component: WebKit2
Assignee: webkit-unassigned at lists.webkit.org
Reporter: mcatanzaro at igalia.com
When compiling with ENABLE_SECCOMP_FILTERS, each WebKitWebProcess forks off a second WebKitWebProcess to broker system calls for the original WebKitWebProcess. This occurs relatively late, after memory is allocated for various purposes that that the broker process doesn't need. Each broker process uses 12.1 MiB (on the GTK+ port), which would be OK if the broker was shared between all web processes, but it's too much when there is a separate broker for each web process.
There are various things we could try to do to fix this:
* fork off the broker process as early as possible. In particular, ChildProcessMain<ChildProcessType, ChildProcessMainType> calls InitializeWebKit2(), which we probably want to avoid if at all possible.
* exec the broker process after forking, so it only uses as much memory as it requires. (This has another advantage: the broker process would not confusingly be named WebKitWebProcess when viewed in top or System Monitor.) We'd need to find some way to get the syscall policy to the broker via IPC before the "real" web process applies the policy.
* Have a single broker handle system calls for all other WebKit processes. This would also require transmitting the syscall policy via IPC, and it might degrade performance. (At least on the GTK+ port, this might well be a good tradeoff.)
--
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/20150105/c666273b/attachment-0002.html>
More information about the webkit-unassigned
mailing list