| 1 |
On Wednesday, 28 April 2021 09:58:57 BST Wols Lists wrote: |
| 2 |
> On 27/04/21 23:00, Michael wrote: |
| 3 |
> > There's three options, I can think of: |
| 4 |
> > |
| 5 |
> > 1. Use dev-lang/rust-bin, as Matt suggested above. |
| 6 |
> > |
| 7 |
> > 2. Buy more RAM, or use a surrogate PC with more RAM to cross-compile it. |
| 8 |
> > |
| 9 |
> > 3. Use a partition with enough space on it to bind mount /var/tmp/portage, |
| 10 |
> > for this package only. |
| 11 |
> > |
| 12 |
> > I use the 3rd option, but I'm wondering if option 1 may be the smartest |
| 13 |
> > move for my needs. |
| 14 |
> |
| 15 |
> 4. Add gazillibytes of swap. With a maximum of 16GB on my mobo, my two |
| 16 |
> disks each have a 32GB swap partition so that's 80GB of "ram" available |
| 17 |
> to my system. My /var/tmp/portage tmpfs is 30GB. |
| 18 |
> |
| 19 |
> So obviously I use option 4 :-) |
| 20 |
> |
| 21 |
> Cheers, |
| 22 |
> Wol |
| 23 |
|
| 24 |
The "add more swap" solution remains feasible, but only for PCs which already |
| 25 |
have adequate RAM. By 'adequate RAM' I mean enough RAM to run the OS, plus at |
| 26 |
least a single compilation thread. With, say, <4G RAM, even a single |
| 27 |
compilation thread of a monster package will end up thrashing your disk |
| 28 |
continuously. The solutions are to set MAKEOPTS="-j1", plus deploy zram for / |
| 29 |
var/tmp/portage, plus add adequate swap and if your swap is on a spinning disk |
| 30 |
also use a better scheduler: |
| 31 |
|
| 32 |
echo bfq > /sys/block/sda/queue/scheduler |
| 33 |
|
| 34 |
Nevertheless, if a bin package exists and does what you need it to do, the |
| 35 |
above gymnastics are probably akin to ricing with substandard hardware. :-) |
Archives