commit 4268d48d4c5fc389bb9f2149aa3249bbc6f99c15
author Benoit Lize <lizeb@chromium.org> Tue Sep 21 12:11:28 2021
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Sep 21 12:11:28 2021
tree b66a3765113b9d7d62c2841687be483b61c5c5bc
parent ac77fafef911cdc0160b38c9a3d867a202e565c5

[PartitionAlloc] Use a larger empty slot span ring buffer on Linux.

Document and change the empty SlotSpan ring buffer limits.

When running Speedometer 2.0 on Linux (release build, no DCHECK()s),
~90-100k system calls are made from PartitionAlloc. A common way for the
allocator to make a system call is when decommitting an empty SlotSpan,
then when a recommit is required.

While this is not necessarily a large performance issue on Linux,
reducing the number of system calls is always a good idea, as most of
them are made with the root lock held, and can incur high tail
latency. Furthermore, while Linux is performing very well with these
calls (from local testing, <1us per call), this is not necessarily the
case of all operating systems.

A way to reduce the number of syscalls is to increase the size of the
ring buffer. This may increase peak committed memory, which we
monitor. Showing the median of 3 runs on a 56 hyperthreads Linux machine
(Xeon "Haswell", core count matters since it is linked to the number of
worker threads Chrome typically creates):

- Size 16:
  - Syscalls: 101k
  - Total syscall time: 812ms
  - Peak committed memory: 36796kiB
- Size 126:
  - Syscalls: 47.9k
  - Total syscall time: 422ms
  - Peak committed memory: 36104kiB

So it *seems* to not impact peak committed memory. Nevertheless, only
bump the size to 127 on Linux, to assess the impact on performance bots.

Bug: 1250288
Change-Id: I83ee913fe57824be21a1b2306b21029b70f5625d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3168880
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Benoit L <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#923342}