Build Appliance 2023 - Revision history

Trevor Woerner: native: update native build time after performing a couple builds

2023-04-14T11:54:02Z

native: update native build time after performing a couple builds

← Older revision		Revision as of 11:54, 14 April 2023
Line 61:		Line 61:
	In the interest of providing a baseline, a <code>$ bitbake core-image-sato</code> build performed directly on my host machine (i.e. without any resource constraints) takes:		In the interest of providing a baseline, a <code>$ bitbake core-image-sato</code> build performed directly on my host machine (i.e. without any resource constraints) takes:

	real ~~86m8~~.~~781s~~		real 78m28.352s
	user ~~1m7~~.~~070s~~		user 0m54.934s
	sys ~~1m36~~.~~769s~~		sys 0m5.896s

	My host build machine has:		My host build machine has:

Trevor Woerner: native: add results for building in a cgroup (comparable to the virtualized environments)

2023-04-14T04:39:48Z

native: add results for building in a cgroup (comparable to the virtualized environments)

@@ Line 53: / Line 53: @@
 Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore comparing the performance of a <code>$ bitbake core-image-sato</code> build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.
-However, in the interest of providing a baseline, a <code>$ bitbake core-image-sato</code> build performed directly on my host machine takes:
+Also, it is hard to setup a build in such a way that the system is dedicated to nothing but the build under test. I didn't go out of my way to try to create a completely quiet system on which to perform the builds, but I did take some steps such as:
   real    86m8.781s
   user    1m7.070s
   sys     1m36.769s
 === qemu ===

Trevor Woerner: add more general details of the test parameters (repository=poky, commit)

2023-04-13T23:10:33Z

add more general details of the test parameters (repository=poky, commit)

← Older revision		Revision as of 23:10, 13 April 2023
Line 47:		Line 47:
	Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.		Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.

	It's important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a <code>$ bitbake core-image-sato --runall=fetch</code> before performing the actual <code>$ bitbake core-image-sato</code> build.		It's important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a <code>$ bitbake core-image-sato --runall=fetch</code> before performing the actual <code>$ bitbake core-image-sato</code> build. Also each build will be run from <code>poky</code> at commit <code>311c76c8e8cf39fa41456561148cebe2b8b3c057</code>.

	=== native ===		=== native ===
Line 53:		Line 53:
	Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore comparing the performance of a <code>$ bitbake core-image-sato</code> build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.		Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore comparing the performance of a <code>$ bitbake core-image-sato</code> build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.

	However, in the interest of providing a baseline, a <code>$ bitbake core-image-sato</code> build ~~from <code>poky:311c76c8e8cf39fa41456561148cebe2b8b3c057</code>~~ performed directly on my host machine takes:		However, in the interest of providing a baseline, a <code>$ bitbake core-image-sato</code> build performed directly on my host machine takes:

	real 86m8.781s		real 86m8.781s

Trevor Woerner: native: add baseline results

2023-04-13T23:08:22Z

native: add baseline results

← Older revision		Revision as of 23:08, 13 April 2023
Line 51:		Line 51:
	=== native ===		=== native ===

	Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore ~~performing an unrestricted~~ build on ~~the~~ host ~~will~~ not ~~be the best comparison~~ since none of the virtualized builds ~~will have any chance~~ of ~~comparing; it won't be an apples~~-to-~~apples comparison~~.		Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore comparing the performance of a <code>$ bitbake core-image-sato</code> build in each of the virtualization platforms versus the same build performed directly on my host machine (i.e. without virtualization) would not provide honest results since none of the virtualized builds would be able to use the same amount of resources for their builds as would my host machine.

			However, in the interest of providing a baseline, a <code>$ bitbake core-image-sato</code> build from <code>poky:311c76c8e8cf39fa41456561148cebe2b8b3c057</code> performed directly on my host machine takes:

			real 86m8.781s
			user 1m7.070s
			sys 1m36.769s

	=== qemu ===		=== qemu ===

Trevor Woerner: add page (not yet complete)

2023-04-13T19:57:45Z

add page (not yet complete)

New page

__TOC__

== Build ==

Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:

<code>$ bitbake build-appliance-image</code>

At a minimum the configuration requires:
* the <tt>MACHINE</tt> should be set to <tt>qemux86-64</tt>
* <tt>DISTRO_FEATURES</tt> must include <tt>opengl</tt>, <tt>x11</tt>, <tt>xattr</tt>
* <tt>VOLATILE_TMP_DIR</tt> must not be set to <tt>yes</tt>

== Usage ==

Currently, building the <tt>build-appliance-image</tt> target generates the following artifacts (among others):
* <tt>build-appliance-image*rootfs.wic.vhd</tt>
* <tt>build-appliance-image*rootfs.wic.vhdx</tt>
* <tt>build-appliance-image*rootfs.wic.vmdk</tt>

The resulting <tt>*vmdk</tt> should be runnable in any of:
* qemu
* virtualbox
* vmware player

=== qemu ===

After successfully building the <tt>build-appliance-image</tt>, from the same shell from which the build was performed, run:

<code>$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk</code>

To quit qemu non-gracefully use: <tt>Ctrl-A + x</tt>

=== virtualbox ===

=== vmware player ===

== Issues ==

Qemu has support for <tt>virtio-blk</tt> and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.

== In-Appliance Build Performance ==

The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.

Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.

It's important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a <code>$ bitbake core-image-sato --runall=fetch</code> before performing the actual <code>$ bitbake core-image-sato</code> build.

=== native ===

Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore performing an unrestricted build on the host will not be the best comparison since none of the virtualized builds will have any chance of comparing; it won't be an apples-to-apples comparison.

=== qemu ===