diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/manual.cli | 41 |
1 files changed, 31 insertions, 10 deletions
diff --git a/doc/manual.cli b/doc/manual.cli index 20e0846..abccb8b 100644 --- a/doc/manual.cli +++ b/doc/manual.cli @@ -34,9 +34,9 @@ mode} and receive \i{build tasks} from their respective agents. \h1#arch|Architecture| Build OS root filesystem (\c{rootfs}) resides entirely in RAM with all changes -(such as installation of the \c{build2} toolchain} discarded on the next +(such as installation of the \c{build2} toolchain) discarded on the next reboot. A small amount of persistent (but not precious) state is stored in -\c{/state} (see \l{#config-storage-state State}). A minimum of 4G of RAM +\c{/state} (see \l{#config-storage-state State}). A minimum of 4GB of RAM is required for Build OS itself (that is, excluding any virtual machines and containers). @@ -180,13 +180,13 @@ sudo kvm \ \h#config-cpu-ram|CPU and RAM| -A Build OS instances divides available CPUs and RAM (minus 4G) into \i{slices} -that are then \i{committed} to each toolchain. If you don't expect your -toolchains to utilize these resources at the same time, then it may make -sense to overcommit them to improve utilization. The respective overcommit -values can be specified as ratios with the \c{buildos.cpu_overcommit} -and \c{buildos.ram_overcommit} kernel command line parameters. For example, -given the following CPU overcommit: +A Build OS instances divides available CPUs and RAM (minus reserved, see +below) into \i{slices} that are then \i{committed} to each instance of each +toolchain. If you don't expect your builds to utilize these resources at the +same time, then it may make sense to overcommit them to improve utilization. +The respective overcommit values can be specified as ratios with the +\c{buildos.cpu_overcommit} and \c{buildos.ram_overcommit} kernel command +line parameters. For example, given the following CPU overcommit: \ buildos.cpu_overcommit=3/2 @@ -195,6 +195,11 @@ buildos.cpu_overcommit=3/2 A Build OS machine with 8 CPUs (hardware threads) and three toolchains will assign 4 CPUs (\c{8 * 3/2 / 3}) to each slice. +It is also possible to reserve a number of CPUs and an amount of RAM to +Build OS with the \c{buildos.cpu_reserved} and \c{buildos.ram_reserved} +(in GB) kernel command line parameters. If unspecified, 4GB of RAM is +reserved by default. + \h#config-storage|Storage| @@ -342,6 +347,19 @@ for example, \c{buildos.toolchain_url.<name>} (values without the toolchain name use the toolchain name \c{default}). The toolchain name may not contain \c{-}. +Each toolchain may also execute multiple \c{bbot} agent instances. The number +of instances is specified with the \c{buildos.instances[.<name>]} parameter. + +All \c{bbot} agent instances of a toolchain are executed with the same nice +value which can be specified with the \c{buildos.nice[.<name>]} parameter. It +should be between -20 (highest priority) and 19 (lowest priority) with 0 +being the default. See \cb{sched(7)} for details. + +The bridge interface to be used for machine networking can be specified with +the \c{buildos.bridge[.<name>]} parameter. Valid values are \c{br0} (public +bridge to the physical interface) and \c{br1} (private/NAT'ed bridge to +\c{br0}). If unspecified, \c{br1} is used by default. + In the checksums file blank lines and lines that start with \c{#} are ignored. If the first line is the special \c{disabled} value, then this toolchain is ignored. Otherwise, each line in the checksums file is the output of the @@ -564,7 +582,10 @@ If the machine has been suspended, it can be resumed using the following command: \ -echo cont | ssh build@build socat - UNIX-CONNECT:/tmp/<toolchain>-monitor +echo cont | ssh build@build socat - UNIX-CONNECT:/tmp/monitor-<toolchain>-<instance> \ +Other useful QEMU monitor commands are \c{system_powerdown} and +\c{system_reset}. + " |