| commit | 208b68cc0906a8042c5518e06921786a0da41abf | [log] [tgz] |
|---|---|---|
| author | Yifei Teng <yifeit@fuchsia.infra.roller.google.com> | Thu Jun 27 05:53:27 2024 +0000 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Jun 26 22:54:42 2024 -0700 |
| tree | ebadbd89d7c6537562ca3e2594574f6c786a4da3 | |
| parent | 5023592466e782aa3c423a07f7e08a7d6e6ae6dd [diff] |
[roll] Roll fuchsia [starnix] PidTable unparks memory attribution monitoring thread In Ifbb5614f450c3ac80a9a3a6005f0019524e61618, we added a memory attribution focused kthread to scan the PidTable every 5 seconds, and computed any differences. That means modifications to the PidTable won't incur additional performance penalties, but the data reported by starnix_kernel will have a 5 second lag in the worst case. This CL tries to improve that latency with the least intrusive change to PidTable. Specifically, the PidTable uses `Thread::unpark()` to wake the attribution monitoring thread, instead of blindly scanning at 5 second intervals. To reduce thrashing, the monitoring thread will only scan once if there were multiple wakes within a 100ms window, which is much better than 5 seconds. This means the PidTable overhead in forking operations becomes a single atomic compare-exchange in the happy path, which is the underlying implementation in `unpark` [1]. [1]: https://github.com/rust-lang/rust/blob/3d5d7a24f76006b391d8a53d903ae64c1b4a52d2/library/std/src/sys/sync/thread_parking/id.rs Perfcompare shows no_sig_diff for all test cases, but I'll copy the fork ones here: fuchsia.microbenchmarks.starnix: Fork.fork no_sig_diff 0.953-1.064 763994 +/- 23452 ns 769419 +/- 18631 ns fuchsia.microbenchmarks.starnix: Fork.wait no_sig_diff 0.940-1.077 144178 +/- 5350 ns 144975 +/- 4474 ns fuchsia.microbenchmarks.starnix: ForkMultiple/64.fork no_sig_diff 0.962-1.071 54970526 +/- 726284 ns 55815924 +/- 2253605 ns fuchsia.microbenchmarks.starnix: ForkMultiple/64.wait no_sig_diff 0.936-1.052 11073225 +/- 396512 ns 10979186 +/- 248088 ns fuchsia.microbenchmarks.starnix: ForkMultiple/8.fork no_sig_diff 0.942-1.068 5581279 +/- 113826 ns 5600790 +/- 236994 ns fuchsia.microbenchmarks.starnix: ForkMultiple/8.wait no_sig_diff 0.961-1.048 1082014 +/- 15220 ns 1086459 +/- 31958 ns fuchsia.microbenchmarks.starnix: ForkMultipleNested/64.fork no_sig_diff 0.806-1.176 73780179 +/- 6993187 ns 71823325 +/- 6689752 ns fuchsia.microbenchmarks.starnix: ForkMultipleNested/64.wait no_sig_diff 0.964-1.035 15412261 +/- 318079 ns 15399454 +/- 227901 ns fuchsia.microbenchmarks.starnix: ForkMultipleNested/8.fork no_sig_diff 0.819-1.274 6213341 +/- 460336 ns 6398003 +/- 930641 ns fuchsia.microbenchmarks.starnix: ForkMultipleNested/8.wait no_sig_diff 0.933-1.072 1395959 +/- 39253 ns 1396671 +/- 57931 ns In the most complex 64-layered nested fork test case, the mean time went from 71.8ms to 73.7ms. But they stayed within the confidence interval. Multiply: starnix_memory_attribution_test Original-Fixed: b/347368123 Original-Fixed: b/346803948 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1068914 Original-Revision: 1bbc5e01199587de42df9ba0c1508230495ccb04 GitOrigin-RevId: 5a3ff262f812cb454d0d1d912b8c7fde97b631b7 Change-Id: If8f3bc6332a49d357464ea7d8680df67ddde7282
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance via the IRC channel #fuchsia on Freenode.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.