1 |
On Friday, 25 October 2019 18:01:57 BST Dale wrote: |
2 |
> Mick wrote: |
3 |
|
4 |
> > PS. In an ideal AI world, portage would know how much memory is necessary |
5 |
> > for a given package and would auto-adjust the number of jobs to minimise |
6 |
> > swapping given any amount of RAM. In an even more ideal world, it would |
7 |
> > be able to do this in real time. :-) |
8 |
> |
9 |
> I agree that it would be nice if emerge could do that automatically, |
10 |
> although I have no clue how to do that or even if it can be done at |
11 |
> all. Back when I had less memory, I could let FF, LOo or another |
12 |
> package run at full speed but only if it was only one of those packages |
13 |
> at a time. Thing is, on occasion two or more of those updates would hit |
14 |
> and due to the long compile times, end up compiling at the same time. |
15 |
> Do you think there is a way for the devs to set up a method to tell |
16 |
> emerge not to emerge certain packages at the same time? In other words, |
17 |
> if Firefox is emerging, LOo is held until it is done or vice versa. |
18 |
> Maybe even have it so others can be listed. The list of large packages |
19 |
> are likely small but they can have a huge impact on systems with less |
20 |
> memory. |
21 |
> |
22 |
> You think that a feature worth asking the devs about? Maybe they can |
23 |
> figure out a way to implement that?? |
24 |
> |
25 |
> Dale |
26 |
> |
27 |
> :-) :-) |
28 |
|
29 |
Well, ebuilds with known large compiles have specific tests at present, e.g. |
30 |
chromium, FF, et al., run checks on available disk space for /var/tmp/portage |
31 |
and warn the user accordingly. In firefox-70.0.ebuild we see this: |
32 |
|
33 |
... |
34 |
pkg_pretend() { |
35 |
# Ensure we have enough disk space to compile |
36 |
if use pgo || use lto || use debug || use test ; then |
37 |
CHECKREQS_DISK_BUILD="8G" |
38 |
else |
39 |
CHECKREQS_DISK_BUILD="4G" |
40 |
fi |
41 |
|
42 |
check-reqs_pkg_setup |
43 |
} |
44 |
|
45 |
I guess a lot can be included in such checks, but I have no idea how to do it, |
46 |
or how complicated an ebuild would get as a result. The problem with RAM |
47 |
usage is that it changes continuously. You open a browser, or some large PDF, |
48 |
or LO and more RAM is being used, just at the moment an ebuild decides to run |
49 |
a check on available RAM. It can't guess if you will shut down your |
50 |
applications and log out of your desktop the next moment to free up more |
51 |
memory, if you will shut down web servers, databases or whatever else you may |
52 |
be running in the background and drop to a console. For this reason I assume |
53 |
such a measure won't be implemented in rush and even if it did, it would annoy |
54 |
people, especially if they are asked to add USE="I-really-know-what-I-am- |
55 |
doing" to allow the compile to start. |
56 |
-- |
57 |
Regards, |
58 |
|
59 |
Mick |