Re: [PATCH 03/25] um/xor: don't override XOR_SELECT_TEMPLATE
Johannes Berg <[email protected]>
| Newsgroups | gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.ppc64.devel,gmane.linux.ports.riscv,gmane.linux.ports.sparc,gmane.linux.uml.devel,gmane.linux.kernel.cryptoapi,gmane.comp.file-systems.btrfs,gmane.linux.kernel.cross-arch,gmane.linux.raid |
|---|---|
| Message-ID | <[email protected]> |
On Thu, 2026-02-26 at 22:45 +0100, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- > > Von: "hch" <[email protected]> > > XOR_SELECT_TEMPLATE is only ever called with a NULL argument, so all the > > ifdef'ery doesn't do anything. With our without this, the time travel > > mode should work fine on CPUs that support AVX2, as the AVX2 > > implementation is forced in this case, and won't work otherwise. > > IIRC Johannes added XOR_SELECT_TEMPLATE() here to skip > the template selection logic because it didn't work with time travel mode. > > Johannes, can you please test whether this change does not break > time travel mode? It does work, even if it reports nonsense (as you'd expect): xor: measuring software checksum speed prefetch64-sse : 12816000 MB/sec sse : 12816000 MB/sec xor: using function: prefetch64-sse (12816000 MB/sec) I think it works now because the loop is using ktime and is bounded by REPS, since commit c055e3eae0f1 ("crypto: xor - use ktime for template benchmarking"). The RAID speed select still hangs, but we've gotten that removed via Kconfig, so that's already handled. Perhaps raid6_choose_gen() should use a similar algorithm? But for UML it doesn't really matter since CONFIG_RAID6_PQ_BENCHMARK exists. As far as AVX2 is concerned, yeah, I guess that was a bug, but evidently nobody (who configured time-travel) ever cared - what _did_ matter though in practice is that the boot not get stuck entirely... Two completely separate issues. johannes