| 1 |
On Sun, 20 Oct 2019 18:01:01 +0100, Mick wrote: |
| 2 |
|
| 3 |
> Now, in a gentoo scenario, say a mammoth compile like Chromium, with a |
| 4 |
> large count of jobs specified for it, you could end up swapping part or |
| 5 |
> all of one or more jobs into memory, only to swap it out again in order |
| 6 |
> to process it. The compile keeps swapping in and out a job at a time in |
| 7 |
> order to carry on compiling. The disk thrashing is now continuous and |
| 8 |
> indeed interacting with your desktop will be painful - potentially |
| 9 |
> waiting for minutes at a time before an application responds. The way |
| 10 |
> out of this bottleneck is to either increase your RAM, or minimise the |
| 11 |
> use of memory by reducing the job count in MAKEOPTS. Shutting down |
| 12 |
> desktop applications and login out of any desktop sessions to release |
| 13 |
> RAM will also help. |
| 14 |
> |
| 15 |
> On a laptop with 4G RAM compiling Chromium is quite challenging when |
| 16 |
> even a single gcc job could grow to 3G or more. Swapping and a disk |
| 17 |
> I/O bottleneck becomes unavoidable and moving the compile of binaries |
| 18 |
> to a bigger PC becomes a rather wise solution. |
| 19 |
|
| 20 |
That's why I have Chromium, as well and LO and qtwebengine, set to use my |
| 21 |
SSD for PORTAGE_TMPDIR on this laptop, which is limited to 8GB. MAKEOPTS |
| 22 |
is also constricted for Chromium. As a result, the packages build more |
| 23 |
quickly with minimal impact on using the system. |
| 24 |
|
| 25 |
|
| 26 |
-- |
| 27 |
Neil Bothwick |
| 28 |
|
| 29 |
Top Oxymorons Number 3: Working vacation |
Archives