Mesh appears to increase memory usage in Chrome
mthiesse opened this issue · comments
Not sure if this counts as an issue, but I figured this was the easiest way to share my results for anybody interested.
I spent some time getting Mesh working in Chrome, which was a bit challenging as Chrome does some interesting things around process creation for security reasons, etc.
For anybody else interested in trying out Chromium with Mesh enabled, here are the steps to get it working on Linux:
- Check out the chromium repo (https://chromium.googlesource.com/chromium/src/+/master/docs/linux_build_instructions.md).
- Apply this patch https://chromium-review.googlesource.com/c/chromium/src/+/1807698 (note that I probably won't maintain it, so you're likely to have to resolve conflicts or fix issues)
- Set the following gn args ($gn args out/Default):
- is_debug = false
- use_allocator = "none"
- use_allocator_shim = false
- Build chromium (autoninja -C out/Default chrome)
- Build mesh with ./configure --no-debug
- Run $ LD_PRELOAD=libmesh.so out/Default/chrome --disable-setuid-sandbox --disable-namespace-sandbox --no-sandbox
Note that both Chrome and Mesh have to be built without debugging - Chrome won't start up in debug mode (not sure why), and Mesh hits debug assertions.
Test procedure
I benchmarked memory usage using Chrome's performance benchmarking tooling, specifically the memory.long_running_desktop_sites benchmark. Here's the command I used:
$ LD_PRELOAD=~/mesh/libmesh.so tools/perf/run_benchmark run memory.long_running_desktop_sites --output-dir perftest --browser-executable=out/Default/chrome --extra-browser-args="--disable-setuid-sandbox --disable-namespace-sandbox --no-sandbox" --browser exact --pageset-repeat=1
Results
Chrome uses tcmalloc by default on Linux, so these numbers are all in comparison to Chrome using tcmalloc with the same flags (and my patch), just without the gn args to customize the allocator and the LD_PRELOAD.
The most reliable number, reported_by_os:system_memory:private_dirty_size increases by 15%
reported_by_os:private_footprint_size (RssAnon + VmSwap) appears to decrease by 42%, but memfd allocations don't seem to be accounted for in RssAnon which may be a kernel accounting bug.
reported_by_chrome:effective_size also looks really promising, but that's only because Mesh returns 0s for mallinfo() right now.
Full results can be found here: results.html.tar.gz
The first column is with Mesh enabled, the second column is with tcmalloc.
I don't plan on digging any deeper into this myself, but others are welcome to.
I should also add that I did compare against libc malloc as well, and Mesh did appear to slightly outperform libc malloc.
We have a utility that @bpowers wrote that we used to perform full memory accounting: https://github.com/bpowers/mstat. This is a pretty accurate way of capturing memory consumption over time. Would be great if you would try that and report those results.
This is super exciting! I would love to hear more, especially if you were able to run under mstat. I would like to try to reproduce locally, but realistically won't have time in the next week or two
Are these observations still valid? Mesh got some important updates, Chromium as well...