Re: Resolved: devel/llvm13 build: "ninja: build stopped: subcommand failed"
Date: Sun, 14 Aug 2022 17:45:54 UTC
> On 2022-Aug-14, at 10:31, Nuno Teixeira <eduardo@freebsd.org> wrote: > > Ok, I will avoid a swap file. > > My actual config shows: > `swapinfo`: > --- > Device 1K-blocks Used Avail Capacity > /dev/nvd0p2 4194304 6036 4188268 0% > --- > and `cat /etc/fstab`: > --- > # Device Mountpoint FStype Options Dump Pass# > /dev/nvd0p1 /boot/efi msdosfs rw 2 2 > /dev/nvd0p2 none swap sw 0 0 > --- > > Any clues how do I do this? You can have more than one swap partition active, such that the total is the size that you want. (I do this to have various freebsd-swap partition sizes available for media that can be used to boot multiple systems with widely varying amounts of RAM: sometimes having, say, 3 partitions in use to get a desired total, for example.) So you could even plug in a new device and create a freebsd-swap type partition on it to add, say, 56 GiBytes of SWAP to what you already have. I've no clue about your other media that you might be able to use, partitioning on media, etc. and so can not be very specific for your context. > Mark Millard <marklmi@yahoo.com> escreveu no dia domingo, 14/08/2022 à(s) 18:21: > On 2022-Aug-14, at 10:15, Nuno Teixeira <eduardo@freebsd.org> wrote: > > > I use ZFS. > > > > I will follow your recomendations and use a swap of 64GB and then test it again. Note that I recommended up to 60 GB total SWAP, not 64 GB total SWAP. 64 GB total would produce warnings about potential mistuning for a 16 GiByte RAM machine. I avoid such configurations. > > In the meanwhile I will take a look at freebsd docs to see how do I increase swap, by adding a new swap file or resize actual one if possible. > > I recommend never using a swap file, only swap partition(s), in order > to avoid deadlocks and such: > > On 2017-Feb-13, at 7:20 PM, Konstantin Belousov <kostikbel at gmail.com> wrote > on the freebsd-arm list: > > . . . > > swapfile write requires the write request to come through the filesystem > write path, which might require the filesystem to allocate more memory > and read some data. E.g. it is known that any ZFS write request > allocates memory, and that write request on large UFS file might require > allocating and reading an indirect block buffer to find the block number > of the written block, if the indirect block was not yet read. > > As result, swapfile swapping is more prone to the trivial and unavoidable > deadlocks where the pagedaemon thread, which produces free memory, needs > more free memory to make a progress. Swap write on the raw partition over > simple partitioning scheme directly over HBA are usually safe, while e.g. > zfs over geli over umass is the worst construction. > === Mark Millard marklmi at yahoo.com