Boot-Time Compute Analysis

• Boot-time compute is defined as the crucial computation, I/O, orchestration, and synchronization steps that transition systems from start-up to a user-ready state.
• Methodologies such as critical-path decomposition, DAG modeling, and granular time measurements are used to isolate bottlenecks in environments like VM provisioning, Docker startup, and LLM training.
• Optimizations focus on caching, deferring non-critical tasks, and parallel processing to reduce latency in systems ranging from Linux cold boot to FHE bootstrapping.

“Boot-time compute” (Editor’s term) denotes the computation, I/O, orchestration, and synchronization that lie on the critical path to a usable execution state. In systems research, this path runs from power-on or scheduler allocation to a user-visible service, a launched virtual machine, a running container, or the first training iteration. In Fully Homomorphic Encryption (FHE), “bootstrapping” denotes the periodic noise-reduction step that restores the ciphertext modulus so that deeper encrypted computation remains possible. Across virtual-machine provisioning, Linux-based consumer electronics, Docker startup, large-scale LLM training, and CKKS-style FHE, recent work shows that boot-time behavior is often dominated not by nominal payload computation but by networking, storage, dependency installation, management-plane contention, synchronization, or memory bandwidth (Jones et al., 2016, Lim et al., 2021, Li et al., 16 Jul 2025, Khan, 16 Feb 2026, Castro et al., 2021).

1. Measurement models and formal definitions

Boot-time compute is defined operationally by elapsed-time intervals and stage decompositions. For VM provisioning on an HPC system, startup time is measured by issuing a batch launch, recording an initial “start” timestamp, receiving a final HTTP “I’m up” callback from each guest in its last cloud-init step, and computing total startup time as $$T_{\mathrm{total}} = T_{\mathrm{last}} - T_{\mathrm{start}}$$; the same study also uses $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$ as a per-VM average time (Jones et al., 2016). For large-scale LLM training, startup overhead is defined as the elapsed time from scheduler allocation to the first training iteration, with the decomposition

$$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$

and, for GPU-waste analysis, practitioners often simplify this to

$$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$

Node-level startup excludes queueing and allocation but includes synchronization delays due to stragglers (Li et al., 16 Jul 2025).

Linux cold boot has also been modeled explicitly as a DAG. In Booting Booster, the full boot procedure is represented as $G=(V,E)$, with tasks as vertices and precedence constraints as directed edges. If $t(v)$ is the isolated execution time of task $v$, then the critical-path length is

$$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$

and an ideal lower bound with $C$ identical CPUs is

$$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$

This formalization makes the distinction between total work and critical-path work explicit (Lim et al., 2021).

Docker startup has been decomposed into kernel, runtime, and storage components:

$t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$0

Here, namespace creation and cgroup setup are CPU-bound primitives, whereas OverlayFS mount behavior, copy-up, and layer metadata access expose storage-tier effects (Khan, 16 Feb 2026). These models collectively frame boot-time compute as a critical-path problem: what matters is not aggregate system capability alone, but the stage whose latency or straggler behavior gates useful execution.

2. Virtual-machine startup in HPC-oriented provisioning systems

In the VM-provisioning literature, startup latency is treated as a key performance metric for HPC because the runtime of any individual task is typically much shorter than the lifetime of a virtualized service in an enterprise context. The comparative study of OpenStack, OpenNebula, and Eucalyptus used four identical HP ProLiant DL165 G7 nodes, each with dual-socket AMD Opteron 6274, 96 GB DDR3 RAM, four 1 TB local disks, KVM, and a Fedora Cloud 22 minimal image instrumented with a final HTTP callback from cloud-init (Jones et al., 2016).

On representative batch sizes of $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$1, measured startup times differed by roughly an order of magnitude. Eucalyptus required approximately $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$2, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$3, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$4, and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$5 seconds; OpenStack approximately $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$6, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$7, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$8, and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$9 seconds; and OpenNebula approximately $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$0, $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$1, $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$2, and $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$3 seconds. For $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$4, OpenNebula was about $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$5 slower than Eucalyptus, and across the full sweep the fastest stack was about $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$6 quicker than the slowest (Jones et al., 2016).

The principal source of delay was not lower-level VM launch or kernel initialization but cloud-init networking. For $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$7, OpenNebula spent about $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$8 of $$T_{\mathrm{startup}} = T_{\mathrm{queue}} + T_{\mathrm{allocation}} + T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}},$$9 seconds in cloud-init networking, OpenStack about $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$0 of $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$1 seconds, and Eucalyptus about $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$2 of $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$3 seconds. Other boot stages—BIOS, initramfs unpack, kernel probe, and systemd services—were roughly constant at about $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$4–$$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$5 seconds and independent of framework. As batch size increased, scheduler and database contention in the management plane added a small incremental delay per VM in OpenStack and OpenNebula, whereas Eucalyptus scaled nearly linearly with about $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$6 s/VM (Jones et al., 2016).

The study’s optimization recommendations were correspondingly concrete: minimize cloud-init network hang time, preload DHCP leases or use a static-IP metadata service, deploy a local HTTP metadata endpoint on every host, patch cloud-init to skip unnecessary data sources or reduce default timeouts, use RAW images where possible, disable unneeded init services and modules, and parallelize orchestration requests. This suggests that, in HPC-oriented VM startup, boot-time compute is primarily a control-plane and guest-initialization problem rather than a hypervisor-execution problem.

3. Linux cold boot and critical-task isolation in consumer electronics

Consumer-electronics boot optimization emphasizes that “boot completion” is not identical to “all services initialized.” Booting Booster, deployed in Samsung Smart TV 2015 models running Linux-based Tizen OS, identifies and isolates booting-critical tasks, defers non-critical tasks, and enables execution of more tasks in parallel (Lim et al., 2021).

The key abstraction is the BB Group, a subgraph $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$7 containing only tasks that are transitively required for user-visible readiness. The Group Isolator performs reverse reachability from a small set $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$8 of completion anchors over reversed edges, with complexity $$T_{\mathrm{startup}} = T_{\mathrm{load}} + T_{\mathrm{env}} + T_{\mathrm{init}}.$$9. In the TV example, $G=(V,E)$0 included seven units—mount, socket, dbus, tuner, hdmi, demux, fasttv—and the backward sweep typically selected about $G=(V,E)$1 out of about $G=(V,E)$2 total units (Lim et al., 2021).

After pruning to $G=(V,E)$3, Booting Booster modifies systemd and the Linux RCU scheme. Units not in $G=(V,E)$4 are moved into a deferred target and not scheduled until after bb-complete.target. Within $G=(V,E)$5, dependencies are preserved, but parallel launch is made more aggressive. The implementation also includes an On-demand Modularizer, an RCU Booster, a Pre-parser that converts service unit files into a single binary blob, and a BB Manager that prioritizes $G=(V,E)$6-tasks via nice() and ioprio_set() (Lim et al., 2021).

The quantitative effect is a cold-boot reduction from about $G=(V,E)$7 s to about $G=(V,E)$8 s, corresponding to an overall speedup of about $G=(V,E)$9 and a $t(v)$0 decrease in cold-boot time. The breakdown includes kernel init from $t(v)$1 ms to $t(v)$2 ms, systemd init from $t(v)$3 ms to $t(v)$4 ms, RCU Booster from $t(v)$5 ms to $t(v)$6 ms, Pre-parser loading time from $t(v)$7 ms to $t(v)$8 ms, and dependency parsing from $t(v)$9 ms to $v$0 ms (Lim et al., 2021). The significance is methodological: boot-time compute can be reduced by redefining readiness as a critical subgraph rather than as the completion of all background work.

4. Docker startup latency across storage tiers and virtualization layers

The Docker measurement study isolates startup latency across Azure Premium SSD, Azure Standard HDD, and macOS Docker Desktop. Using overlay2, Linux file-system cache control for cold starts, pre-pulled images for warm starts, and $v$1 warm-start repetitions, it reports mean, standard deviation, and $v$2 confidence intervals for container startup and ancillary operations (Khan, 16 Feb 2026).

A central empirical result is that warm-start latency is dominated by runtime overhead rather than image size. On SSD, alpine:latest at $v$3 MB measured $v$4 ms, nginx:latest at $v$5 MB measured $v$6 ms, and python:3.11-slim at $v$7 MB measured $v$8 ms, for only $v$9 variation across the range. By contrast, storage-tier selection imposed a $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$0 startup penalty for Alpine, with HDD at $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$1 ms versus SSD at $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$2 ms; the HDD/SSD ratio rose to $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$3 for nginx and $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$4 for python (Khan, 16 Feb 2026).

The hypervisor layer in Docker Desktop added further overhead and variance. Alpine measured $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$5 ms on macOS Docker Desktop versus $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$6 ms on SSD-backed native Linux, a $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$7 penalty, while nginx and python exhibited $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$8 and $$L_p(G)=\max_{p\in\mathrm{Paths}(G)} \sum_{v\in p} t(v),$$9 penalties. The coefficient of variation was $C$0 higher on macOS, and CPU throttling variance under --cpus=0.5 was $C$1 higher than on SSD-backed Linux (Khan, 16 Feb 2026).

The storage-path results were heterogeneous. For 256 MB sequential writes on SSD, OverlayFS achieved $C$2 MB/s while a volume mount achieved $C$3 MB/s, a ratio of $C$4; on HDD, OverlayFS achieved $C$5 MB/s versus $C$6 MB/s for volumes. On the other hand, metadata creation on HDD favored OverlayFS: for a 500-file create, OverlayFS took $C$7 ms versus $C$8 ms for a volume mount, or $C$9 faster. Namespace creation contributed only $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$0 ms on SSD and $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$1 ms on HDD, less than $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$2 of total warm-start time (Khan, 16 Feb 2026). The practical implication is that container boot-time compute depends far more on runtime and storage behavior than on namespace primitives or image minimization alone.

5. Startup overhead in large-scale LLM training

In large-scale LLM training, startup overhead is the delay between resource assignment and the first training iteration. Production evidence in BootSeer indicates that, in one training cluster, more than $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$3 of GPU time is wasted due to startup overhead alone. The profiling methodology injects lightweight logging calls at the entry and exit of each stage on every GPU node, streams timestamped events to a centralized Stage Analysis Service, and over one week covered more than $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$4 jobs requesting over $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$5 GPUs (Li et al., 16 Jul 2025).

Three startup bottlenecks were identified: container image loading, runtime dependency installation, and model checkpoint resumption. In LLM training, container images range from $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$6 GB to $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$7 GB, and even with block-level lazy loading $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$8 typically lies between $$T_n^* \ge \max\Bigl(L_p(G),\,\frac{\sum_{v\in V} t(v)}{C}\Bigr).$$9 s and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$00 s. Environment setup dominates GPU-waste overhead at about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$01 s to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$02 s per node and accounts for roughly $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$03 of total startup in typical mid-sized jobs. Checkpoint resumption adds about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$04 s to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$05 s, and checkpoints can exceed $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$06 GB (Li et al., 16 Jul 2025).

At $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$07 GPUs, the reported average baseline startup breakdown was about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$08 s for image loading, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$09 s for environment setup, and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$10 s for model initialization, for a total of about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$11 s. Straggler severity was quantified by a Max/Median ratio, and for environment setup this ratio grew from about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$12 at small scales to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$13–$t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$14 for jobs exceeding $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$15 GPUs (Li et al., 16 Jul 2025).

BootSeer addresses these bottlenecks with hot block record-and-prefetch, dependency snapshotting, and striped HDFS-FUSE. Across 16, 32, 48, 64, and 128 GPU MOE training jobs, it reduced end-to-end startup from $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$16 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$17 s, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$18 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$19 s, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$20 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$21 s, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$22 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$23 s, and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$24 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$25 s, respectively, or about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$26–$t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$27. At $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$28 GPUs, image loading improved from $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$29 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$30 s, environment setup from $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$31 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$32 s, and model init from $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$33 to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$34 s. The environment cache collapsed the Max/Median ratio for dependency installation to near $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$35, effectively eliminating stragglers in $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$36-GPU jobs (Li et al., 16 Jul 2025). The study also notes trade-offs: cache invalidation on parameter changes, HDFS capacity use, versioning requirements for prefetch metadata, and increased complexity in checkpoint striping.

6. FHE bootstrapping as a memory-bound form of boot-time compute

In FHE, bootstrapping has a distinct meaning from system startup. It is the operation that synthetically restores the modulus and resets noise by homomorphically evaluating an approximation to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$37 on an encrypted value. In CKKS-style FHE, the procedure comprises Modulus-Raise, Coefft↔Slot transforms, polynomial approximation, and Rescale; the CoeffToSlot and SlotToCoeff transforms each use a sequence of small matrix-vector multiplies to realize an $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$38 DFT (Castro et al., 2021).

The architectural analysis defines arithmetic intensity as

$t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$39

For representative CKKS parameters, high-level bootstrapping stages remain below $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$40 Op/byte: CoeffToSlot at $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$41, PolyEval at $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$42, and SlotToCoeff at $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$43. At a realistic GPU bandwidth of $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$44 GB/s, each major phase alone demands $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$45–$t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$46 ms of pure data movement (Castro et al., 2021).

The reason is the working-set size and access pattern. A single ciphertext at $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$47 and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$48 occupies about $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$49 MiB, while the working set of one ciphertext plus associated switching keys requires more than $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$50 MiB of cache. Limb-wise and slot-wise access patterns stress different DRAM rows and banks, so the implementation is heavily bound by main memory bandwidth. The paper therefore concludes that secure implementations of bootstrapping exhibit low arithmetic intensity, require large caches, and are heavily bound by the main memory bandwidth (Castro et al., 2021).

The proposed optimizations are consequently cache-centric rather than purely arithmetic: macro-fusion of $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$51 limbs, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$52-limb caching, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$53-limb caching, re-ordering limb computations, key-switch double-hoisting, hoisting ModDown out of HRotate, and key compression via PRNG. Collectively these raise arithmetic intensity from $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$54 Op/byte to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$55 Op/byte and reduce DRAM transfers from $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$56 GB to $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$57 GB, a $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$58 reduction. In the architectural model, the fully optimized design reaches $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$59 throughput units, compared with $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$60 for Jung et al., $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$61 for Bossuat et al., and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$62 for Samardzic et al. (Castro et al., 2021). Even so, the conclusion remains that bootstrapping continues to be bottlenecked by main memory bandwidth.

7. Recurring patterns, misconceptions, and research implications

Across these domains, the bottleneck in boot-time compute recurrently appears outside the nominal “main” computation. In VM provisioning, cloud-init networking dominates launch latency; in Linux TV boot, non-critical tasks inflate elapsed time until they are deferred behind bb-complete.target; in LLM training, runtime dependency installation and checkpoint resumption dominate GPU-waste overhead; and in FHE, the primary constraint is memory traffic rather than arithmetic throughput (Jones et al., 2016, Lim et al., 2021, Li et al., 16 Jul 2025, Castro et al., 2021).

A common misconception is that reducing payload size or accelerating low-level primitives is sufficient. The Docker study found only $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$63 startup variation across $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$64 MB, $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$65 MB, and $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$66 MB images on SSD, and namespace creation contributed only $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$67–$t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$68 ms, less than $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$69 of warm-start time. The FHE analysis similarly found that even a best-case optimized implementation remains memory-bound, so bespoke high-throughput arithmetic units alone yield only marginal benefit until the memory bottleneck is addressed (Khan, 16 Feb 2026, Castro et al., 2021).

Another recurring theme is straggler control. BootSeer uses the Max/Median ratio to quantify stage imbalance and reduces this ratio to near $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$70 for dependency installation at $t_{\mathrm{avg}}(N)=T_{\mathrm{boot}}(N)/N$71 GPUs; the VM provisioning study attributes part of the scaling gap in OpenStack and OpenNebula to scheduler and database contention; and Booting Booster shortens the critical path by excluding non-essential nodes from the user-visible readiness subgraph (Li et al., 16 Jul 2025, Jones et al., 2016, Lim et al., 2021). This suggests that boot-time compute is often best optimized by narrowing the critical path, localizing data and metadata services, caching hot working sets, and deferring or parallelizing work that does not define readiness.

The literature therefore treats boot-time compute not as a single mechanism but as a class of latency-critical initialization processes. Its unifying analytical feature is that useful execution is gated by a small set of serial or straggler-sensitive stages. Whether the system is launching virtual machines, constructing containers, bringing up a Linux device, resuming a distributed training job, or refreshing an encrypted ciphertext, the governing question is the same: which initialization steps actually determine readiness, and which are merely background work that can be cached, deferred, fused, or removed?