From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gandalf.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id E816E5A0271 for ; Fri, 26 Apr 2024 04:01:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1714096870; bh=baQFC7TUODZIzi6fwjq29z1/5mYFH80NryNEz4yD0g0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bE2P5lVY2G8PsvdfvDMKxXSKAO2aRZBYQvURIFDlHC5+N8SLXFdK3u8jDnputLTw/ 9evxm3yzF7yn2Y/Y+hUIKqQSklB39YewExV3IYhiXYC4iwsmW9bOewX4fyapHFewKF CjcehPfLnKt+WkChOZGY9CnUQ/dVrfMy5Yx22xNXr9XOq8twm9JysEY7kJqEam34iA RIun/Mt23rcuFwU/cpnVwiCJz6zKscat4U4rLdzNbm48Vs5stUMdLWaiy4PP3qAJOi ZPc5AKiDDijrkpc8RKPON+0U6ey8gstUTa+6q+SGA+EiDk1DBua51tLhurLfQy3bQh vmrgvzqLVVnuw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4VQbYL5693z4x0l; Fri, 26 Apr 2024 12:01:10 +1000 (AEST) Date: Fri, 26 Apr 2024 11:46:02 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 3/4] Split "auto" compression mode into its own path Message-ID: References: <20240322022739.2746102-1-david@gibson.dropbear.id.au> <20240322022739.2746102-4-david@gibson.dropbear.id.au> <20240405201002.48d48651@elisabeth> <20240425064605.2e3ffa81@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3qqdAgJkcoS80X5C" Content-Disposition: inline In-Reply-To: <20240425064605.2e3ffa81@elisabeth> Message-ID-Hash: FAG6V6W7PLTVI3TYS6O55VHG6EOE3SQ5 X-Message-ID-Hash: FAG6V6W7PLTVI3TYS6O55VHG6EOE3SQ5 X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: lvivier@redhat.com, passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --3qqdAgJkcoS80X5C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2024 at 06:46:05AM +0200, Stefano Brivio wrote: > On Sat, 6 Apr 2024 14:06:39 +1100 > David Gibson wrote: >=20 > > On Fri, Apr 05, 2024 at 08:10:02PM +0200, Stefano Brivio wrote: > > > On Fri, 22 Mar 2024 13:27:38 +1100 > > > David Gibson wrote: > > > =20 > > > > mbuto supports "auto" compression mode where we detect the fastest > > > > compressor and use it. This is structured a bit oddly - cpio_compr= ess() > > > > first handles the case of an explicitly selected compressor, then h= andles > > > > the auto-detected case, redundantly actually implementing the compr= ession > > > > once it has picked one. =20 > > >=20 > > > Yes, we don't want to risk keeping around several formats if the > > > archives are big... but you're not changing this, right? =20 > >=20 > > I don't believe so, no. > >=20 > > > > Make this a bit clearer: first handle the "auto" case by calling ou= t to > > > > the testing code, and using that to set the parameter for the speci= fic > > > > compression path. > > > >=20 > > > > Signed-off-by: David Gibson > > > > --- > > > > mbuto | 53 ++++++++++++++++++++++++----------------------------- > > > > 1 file changed, 24 insertions(+), 29 deletions(-) > > > >=20 > > > > diff --git a/mbuto b/mbuto > > > > index 49d032c..550f76e 100755 > > > > --- a/mbuto > > > > +++ b/mbuto > > > > @@ -566,31 +566,11 @@ cpio_init() { > > > > fi > > > > } > > > > =20 > > > > -# cpio_compress() - Compress archive, test available methods if no= ne is selected > > > > +# compress_select() - Try compressors and pick the fastest =20 > > >=20 > > > Now we can say we pick the fastest, but it's not clear in what: we ca= re > > > about decompression, so perhaps: > > >=20 > > > # compress_select() - Try compressors and pick the fastest to decompr= ess image > > >=20 > > > ? =20 > >=20 > > I don't think that's accurate. AFAICT the code is selecting the > > fastest to compress, not decompress, >=20 > No, why? Look: >=20 > __start=3D$("${CAT}" /proc/uptime) > __start=3D"${__start% *}" >=20 > for _ in $("${SEQ}" 1 5); do > "${CP}" "${compress_test1}" "${compress_test2}" > ${__cmd} --force -d -c "${compress_test2}" > /dev= /null > done >=20 > __end=3D$("${CAT}" /proc/uptime) > __end=3D"${__end% *}" >=20 > see the '-d' there ('-c' is usually '--stdout'). Oh, yes. My mistake. > > and I didn't change that. I agree that optimizing decompression > > speed would make more sense. > >=20 > > Honestly, I'm not really convinced that the auto mode is useful > > anyway: even if we changed to decompression speed, the speed on the > > location running mbuto isn't necessarily the same as on the target > > doing the decompression (though given mbuto's usage model, it's > > lkely). >=20 > Well, it's exactly the intended usage -- any other usage would be > rather tricky (at least, anything with a different architecture for the > guest). That's how the current passt test suite uses it, too. And it > really makes a difference if you're working with kselftests. Hm, ok. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --3qqdAgJkcoS80X5C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmYrB1kACgkQzQJF27ox 2GeCshAAnaOGiGYkg8KdQEUhfZlsxl2zMaTDvuxPzjfEWY9NS1JjQXnnZiz6vgSR SnB8WEvd3zHTRD46Vu1/nGpHY3uGEp9X0BhHqeGsNG437xOkcXM0eiJZbODMFC6A e8auWX/hIN3dSptZ2Mml0+YBIx5+Uyir8YTdif++7rEEapbhlp68wBun6k+yyDKG hX093BL0yCNz/dq0hm/pkEud6+NDQMpfWVqbSEeQ9ViiO3/2uEG5teO/lS2I+VDg YU1ThVjDnMW6vqd4sAK6XIHrPTnKzEPcv20GWFUJt7n6ty74HErZg4tp+SMlhB/p x3I3bhRqgvEodxGLULLnWJKdDRbL1NfDySGfsd8DKRm+lwXDn3VGlxEg/YOXRxwY nF7usjx4Yd7fDRH1XFNH44MWG/4QrU24lOYVPH1+IAr8oIo928x241FXMggIXqSJ cwAbNiabCf6F/rdSkfAkrU41KZiK0WMmVYqKIRtrnbtkzOcFHG/SpJwYwIpX2G1d KrkpNuDcgZU71cpVyIXyty++GUVzGKyPZKqsvw/X/xzi0Of2oJGvffGVsD57rmPg L4sE47M1l0qCTH8mjz/h7zyVOgrLGr1/y48rDcumWTC3ajP1ggvqUuEk3qLu4/Pq AKGlIexEaNxlnIjgutYOb443j5jhVA5+ij5gwp4BKlOmU+UX+r0= =mFWR -----END PGP SIGNATURE----- --3qqdAgJkcoS80X5C--