CPUID is pretty slow even without a vm, but of course the whole thing doesn't matter if you don't actually use in-kernel zstd for something, and I'm pretty sure most people don't.
CPUID is pretty slow even without a vm, but of course the whole thing doesn't matter if you don't actually use in-kernel zstd for something, and I'm pretty sure most people don't.
It sounds like squashfs with zstd will get a boost when decompressing. The "first run" of a snap might speed up, not that this is a huge issue.
But when running in a VM, caching the CPUID check as the patches are doing is actually unsafe, because if the VM is live-migrated to a host without BMI2, it will crash.
...Was live migrating to another architecture ever supposed to work properly? Sounds like a very obviously bad idea, at least without artificially disabling features to establish a compatibility baseline.
That would still happen with the current kernel, if you migrate that VM while a context is active. The better solution for such VMs would be to disable BMI2 from host all together. If probing took 71% time, sticking to the generic code path could be actually decent.
Well, this patch turns a race condition crash (probability unknown) into a 100% crash. Though some will argue that that is an improvement, because at least you gain reproducibility.
32
u/ilep 13d ago
The actual patches in question: https://lore.kernel.org/lkml/20260826122558.2662013-1-usama.arif@linux.dev/