> On Aug 4, 2020, at 8:16 AM, Arvind Sankar <nived...@alum.mit.edu> wrote: > > On Tue, Aug 04, 2020 at 10:32:36AM +0200, Pavel Machek wrote: >> Hi! >> >>>>> I've measured the kernel decompression speed using QEMU before and after >>>>> this patch for the x86_64 and i386 architectures. The speed-up is about >>>>> 10x as shown below. >>>>> >>>>> Code Arch Kernel Size Time Speed >>>>> v5.8 x86_64 11504832 B 148 ms 79 MB/s >>>>> patch x86_64 11503872 B 13 ms 885 MB/s >>>>> v5.8 i386 9621216 B 91 ms 106 MB/s >>>>> patch i386 9620224 B 10 ms 962 MB/s >>>>> >>>>> I also measured the time to decompress the initramfs on x86_64, i386, >>>>> and arm. All three show the same decompression speed before and after, >>>>> as expected. >>>>> >>>>> [1] https://github.com/lz4/lz4/pull/890 >>>>> >>>> >>>> Hi Nick, would you be able to test the below patch's performance to >>>> verify it gives the same speedup? It removes the #undef in misc.c which >>>> causes the decompressors to not use the builtin version. It should be >>>> equivalent to yours except for applying it to all the decompressors. >>>> >>>> Thanks. >>> >>> I will measure it. I would expect it to provide the same speed up. It would >>> be great to fix >>> the problem for x86/i386 in general. >>> >>> But, I believe that this is also a problem for ARM, though I have a hard >>> time measuring >>> because I can’t get pre-boot print statements in QEMU. I will attempt to >>> take a look at the >>> assembly, because I’m fairly certain that memcpy() isn’t inlined in master. >>> >>> Even if we fix all the architectures, I would still like to merge the LZ4 >>> patch. It seems like it >>> is pretty easy to merge a patch that is a boot speed regression, because >>> people aren’t >>> actively measuring it. So I prefer a layered defense. >> >> >> Layered defense against performance-only problem, happening on >> emulation-only? >> >> IMO that's a bit of overkill. > > Why would it be emulation-only? QEMU is just being used for ease of > testing, but the performance impact should be similar on bare metal.
In addition, I want the decompressors to be fast in the pre-boot for all architectures. Not everyone is going to know that zstd and lz4 require memcpy to be inlined or they are 10x slower, that is an implementation detail of the library. It is a performance gotcha that I’d rather not have.
