Repository navigation
Tile AMI: prefetch the first boot's root volume pieces - #1407
Conversation
…uvm-tools node A tile launched from the AMI took 45 to 84 s to its first frame (on demand, three launches; 86 s on one spot launch). The root volume is made from the AMI's snapshot and fetches each block from S3 on its first read: on the 728be8c image systemd-modules-load took 35.4 s (190 MiB of NVIDIA modules) and the renderer unit 8.7 s, with 14 s from podman's image pull to the container's init. - tile/resident.py lists, with mincore, the byte ranges of root volume files that a tile's page cache holds after its first frame (2,825 pieces of 2,422 files, 421 MiB), the NVIDIA modules first. build.sh `trace` writes it to /etc/fcvm-fleet/prefetch.list and refuses a boot that already ran the prefetch; `bake` refuses an image without a list unless NO_PREFETCH_LIST=1. - tile/prefetch.c is a static reader (256 threads, 1 MiB pieces, list order) that build.sh compiles into /usr/local/lib/fcvm-fleet/prefetch. - fcvm-fleet-prefetch.service is wanted by sysinit.target and ordered after nothing, so it runs beside systemd-modules-load instead of ahead of it. - fcvm-fleet-renderer.service waits for /dev/nvidia-uvm-tools before podman: with the faster boot every launch logged "failed to stat CDI host device" and restarted after 2 s. - measure-boot.sh tile prints systemd-analyze, cloud-init stages, the renderer journal and the root volume's read counters after the first frame, and takes VOLUME=Throughput=...,Iops=... for the root volume. Measured on a g4dn.xlarge, on demand, launch request to first frame over HTTPS: 84.2, 45.5, 58.6 s before; 36.6, 32.0, 33.5 s with the prefetch. Reading the 421 MiB (256 readers) from a volume made from the AMI's snapshot took 2.8 to 6.2 s at gp3 defaults, 1.8 s at 500 MiB/s, 0.55 s at 1000 MiB/s and 4000 IOPS; a volume initialization rate of 300 MiB/s took 6.2 s. Tile launches with 1000 MiB/s and 4000 IOPS reached the first frame in 19.5 s, with 500 MiB/s and 3000 IOPS in 24.9 s. Tests: fleet/ami/check.sh pins the unit (no ordering, wanted by sysinit.target, conditioned on the list), build.sh enabling it and building the binary, bake and trace refusals, the renderer's wait before podman, prefetch.c's reads of listed pieces (compiled and run on a fixture), and resident.py's ranges, skip list, module ordering and recent-file filter.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Caution Review failedThe pull request is closed. Walkthrough
Merge Risk:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 990188c466
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…ot's active state A oneshot without RemainAfterExit never enters the active state, so ActiveEnterTimestampMonotonic read 0 after a successful run (checked with a oneshot unit on a systemd host) and the guard in build.sh trace never fired. The prefetch unit now touches /run/fcvm-fleet-prefetched and trace refuses when it exists. check.sh fails on the previous build.sh.
ejc3
left a comment
There was a problem hiding this comment.
NOT-A-DEFECT: the Codex receipt and CodeRabbit summary bodies carry no finding of their own; the one inline finding is answered and resolved above.
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Prefetch the tile image's first-boot root volume pieces so a fresh EC2 tile reaches its first frame in about 33 s instead of 45 to 84 s.
Cause: the root volume of a tile is made from the AMI's snapshot and fetches each block from S3 on its first read. On the 728be8c tile image
systemd-modules-loadtook 35.4 s (190 MiB of NVIDIA modules) and the renderer unit 8.7 s, with 14 s from podman's image pull to the container's init. Same mechanism as #1370 and #1397 for the host image.Changes (all under fleet/ami):
tile/resident.py+build.sh trace: list the byte ranges of root volume files in the page cache of a tile that served its first frame (2,825 pieces of 2,422 files, 421 MiB, modules first).tracerefuses a boot that ran the prefetch;bakerefuses an image without a list (NO_PREFETCH_LIST=1for the first image of a lineage).tile/prefetch.c: static reader, 256 threads, 1 MiB pieces, list order. Built bybuild.sh.tile/fcvm-fleet-prefetch.service: wanted bysysinit.target, ordered after nothing, so it runs besidesystemd-modules-load.fcvm-fleet-renderer.servicewaits for/dev/nvidia-uvm-tools: with the faster boot every launch loggedfailed to stat CDI host deviceand restarted after 2 s.measure-boot.sh tileprints systemd-analyze, cloud-init stages, the renderer journal and the root volume read counters after the first frame;VOLUME=Throughput=..,Iops=..sets the root volume.Measured (g4dn.xlarge, on demand, launch request to first frame over HTTPS, spot had no capacity):
systemd-analyze blame: modules-load 35.4 s -> 4.0 s, renderer unit 8.7 s -> 2.9 s, prefetch unit 5 s beside them.EBS settings (reading the 421 MiB, 256 readers, from a volume made from the AMI's snapshot): gp3 default 2.8 to 6.2 s; 500 MiB/s 1.8 s; 1000 MiB/s + 4000 IOPS 0.55 s; 1000 MiB/s + 16000 IOPS 0.42 s; volume initialization rate 300 MiB/s 6.2 s (no better than default, as in #1397). Whole-tile launches: 1000 MiB/s + 4000 IOPS 19.5 s, 500 MiB/s + 3000 IOPS 24.9 s, default 32 to 37 s. This PR does not change the volume; the launch templates are in ejc3/aws and the throughput costs extra per volume-hour, so that is a separate decision.
Tests:
bash fleet/ami/check.sh(shellcheck, bash -n, and fixtures for the unit's ordering, enable and build lines, the bake and trace refusals, the renderer's wait, prefetch.c compiled and run on listed pieces, resident.py's ranges, skip list, module ordering and recent-file filter). New checks fail on main because the files and lines are absent. CI does not run check.sh.Contract: tile image recipes only; the AMI is rebuilt from main after this merges and moved in ejc3/aws.
Summary by CodeRabbit