Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp141932pxa; Tue, 4 Aug 2020 01:35:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzAlZOTv9p3qoW88BCdpW+DcNDhLYOBmRBfk1C4WlIMDuRZZuQ9Vx92Q6GJ20ZQ4lEtF/3e X-Received: by 2002:a17:906:a253:: with SMTP id bi19mr19749055ejb.338.1596530153330; Tue, 04 Aug 2020 01:35:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596530153; cv=none; d=google.com; s=arc-20160816; b=CkL8t190wCRaMOrwL9rzgX4UVc2yikSKSBhiI2BLEyNUGVmwKfbLCqs8UZ8mw66cyo eSxW0zqpE63YK61w2yHDDX5V4xjIp6RqN02NWii+YAlnEseYmvxhoYw7vgs1yqXmRXYd qyODK275IjakFe9dJgXfJnDyXZkImfraCqK/8znW/bFTPO7iRXzZQ6V6iu57bKAGZlNG 9lHiud/c/RoVUMI8ekBOFFSIa6ZM8AYT9BuwxmC3b0rzTqVTQ8u0xUJvbRKFUtA2HFMC 5EtQeRzZKWOroFylhxicGZIL2UYiXPYvzU856vwHTRLTpD1d5pT/fh5y0mCnPliGSNJU b+Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=qYZNnwm7EzNe+fw8y0oKE2wzm9B6xZymGaKDZ77Ncc0=; b=cfuofzkYmmBNesq/4ZWbBUFIzboL2WELS8xFrBW3y/PZDQGWVEYVfX9nUL3F3M8CY6 Yz6NJ7QFpjNy3lAOAWXkI1Bg2xvKTj/cKOWYLqe2fFImWnbo9N4+6R25HlFND/renbsQ tnMWO6EecILp/loPKzRtjncTGya8bh3UAc1lP7uB0cg3F+9z3ntejEGqf6uAvLH8Xt+a kG+ALTkxJ3L7UIan1V4RZUtlRAil016icxIl/zl31VCqVpjkKlUtm6inLj6Zzqs5uySQ erRLBaSPcT868gKd9dgrRcrBrhx6tC3q9+pAyI4kEul1z9NbmZdO0iInxG60VyA74yuC rbTg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k8si11769566ejb.67.2020.08.04.01.35.30; Tue, 04 Aug 2020 01:35:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729586AbgHDIc5 (ORCPT + 99 others); Tue, 4 Aug 2020 04:32:57 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:52832 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726058AbgHDIc5 (ORCPT ); Tue, 4 Aug 2020 04:32:57 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 82EB01C0BDD; Tue, 4 Aug 2020 10:32:51 +0200 (CEST) Date: Tue, 4 Aug 2020 10:32:36 +0200 From: Pavel Machek To: Nick Terrell Cc: Arvind Sankar , Nick Terrell , Ingo Molnar , Linux Kernel Mailing List , X86 ML , Kernel Team , Yann Collet , Gao Xiang , Sven Schmidt <4sschmid@informatik.uni-hamburg.de>, Andrew Morton , Greg Kroah-Hartman , Linus Torvalds Subject: Re: [PATCH] lz4: Fix kernel decompression speed Message-ID: <20200804083236.zjkmfer37z5rn3r4@duo.ucw.cz> References: <20200803194022.2966806-1-nickrterrell@gmail.com> <20200803215747.GA1644409@rani.riverdale.lan> <3961E1BD-8F58-4240-A3B3-B7032A405B42@fb.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="unkgxepgdpqe5p3t" Content-Disposition: inline In-Reply-To: <3961E1BD-8F58-4240-A3B3-B7032A405B42@fb.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --unkgxepgdpqe5p3t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > >> I've measured the kernel decompression speed using QEMU before and aft= er > >> this patch for the x86_64 and i386 architectures. The speed-up is about > >> 10x as shown below. > >>=20 > >> 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 > >>=20 > >> 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. > >>=20 > >> [1] https://github.com/lz4/lz4/pull/890 > >>=20 > >=20 > > 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. > >=20 > > Thanks. >=20 > I will measure it. I would expect it to provide the same speed up. It wou= ld be great to fix > the problem for x86/i386 in general. >=20 > But, I believe that this is also a problem for ARM, though I have a hard = time measuring > because I can=E2=80=99t get pre-boot print statements in QEMU. I will att= empt to take a look at the > assembly, because I=E2=80=99m fairly certain that memcpy() isn=E2=80=99t = inlined in master. >=20 > 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=E2=80=99t > 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. Best regards, Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --unkgxepgdpqe5p3t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCXykdJAAKCRAw5/Bqldv6 8h/YAJ9snZA+NN1irCzUGWNHAFTqDZBRWwCfTSqvSSxHl3MvQJU0X6gUeYYRRQ8= =6uB0 -----END PGP SIGNATURE----- --unkgxepgdpqe5p3t--