[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