Skip to content

pressure-vessel: Speed up graphics driver discovery by operating in parallel

Simon McVittie requested to merge wip/smcv/threaded-enumeration into master

  • pv-runtime: Convert the graphics provider into an object

    This encapsulates both the PROVIDER_GRAPHICS_STACK flag and the associated paths: if the object is null then the paths are meaningless, and if the object is non-null then they are meaningful.

    Making this an immutable "value object" also means we can share it between threads, unlike PvRuntime, which has state. This could become important if we want to make graphics driver enumeration multi-threaded to speed up pressure-vessel.

  • pv-runtime: Use threads to enumerate graphics drivers in parallel

    SrtSystemInfo is not thread-aware, but can safely be handed off from one thread to another, and caches its results internally; so we can use a thread per architecture, plus an extra thread for cross-architecture Vulkan and EGL ICDs, to enumerate graphics drivers and populate the cache in parallel with any other container setup. We join the threads just before looking at their results, to maximize the length of time for which we're running in parallel.

    On slow hardware (Lenovo T520 circa 2011, with 500G 7200rpm HDD) this cuts something like 20% off the setup time with a cold cache (echo 3 | sudo tee /proc/sys/vm/drop_caches). It also has a benefit (more like 15%) with a warm cache, immediately after a previous pressure-vessel run.

    This does make it somewhat harder to profile pressure-vessel, because when two I/O-bound operations run in parallel, they both take longer than they otherwise would, even though the overall task finishes sooner; this makes it hard to attribute I/O cost to particular actions. The new --single-thread option can be used to get a better idea of where the time is really going.

  • pv-wrap: Measure total PvRuntime setup time

    This is helpful when trying to reduce this time by parallelizing.

In particular, this is helpful when switching back from unpacking a tarball into var/deploy-* to using an unpacked runtime, copying it to var/tmp-* with --copy-runtime so that we can apply metadata fixups and/or an overlay (!295 (merged)).

With this change, enumerating each architecture's drivers can happen in parallel with the main thread unpacking a new tarball if used, cleaning up old var/tmp-* if any, copying the runtime to a new var/tmp-* if used, and applying metadata fixups if used.

Merge request reports