| 1 |
Roy Bamford wrote: |
| 2 |
> On 2022.01.05 20:22, Sam James wrote: |
| 3 |
>> |
| 4 |
>>> On 5 Jan 2022, at 19:02, Roy Bamford <neddyseagoon@g.o> |
| 5 |
>> wrote: |
| 6 |
>>> Sam, |
| 7 |
>>> |
| 8 |
>>> Do users with FEATURES=distcc still have to opt out of this |
| 9 |
>>> MAKEOPTS clamping? |
| 10 |
>>> |
| 11 |
>> Great point! I think we could add an exemption for that and make it a |
| 12 |
>> noop or warning-only. |
| 13 |
>> |
| 14 |
>> Best, |
| 15 |
>> sam |
| 16 |
>> |
| 17 |
>> |
| 18 |
> |
| 19 |
> Sam, |
| 20 |
> |
| 21 |
> You are building a better mousetrap here. That's not a reason to try. |
| 22 |
> |
| 23 |
> Do users of I_KNOW_WHAT_I_AM_DOING, who have already |
| 24 |
> opted to shoot themselves in both feet, get a free pass here? |
| 25 |
> |
| 26 |
> There are users who run emerge --jobs=X with MAKEOPTS='-jY" |
| 27 |
> and get firefox, thunderbird and libreoffice all building concurrently |
| 28 |
> as they allow X * Y MAKE threads, reduced by this proposed |
| 29 |
> throttling, still triggering the OOM. |
| 30 |
> |
| 31 |
> I don't think you can head that off beforehand. |
| 32 |
> |
| 33 |
|
| 34 |
|
| 35 |
As a user, can I get a large +1 to that. For me, it is usually |
| 36 |
Seamonkey, Firefox, Libreoffice, that big qt package or some combination |
| 37 |
of two or more of them. I've had times where all of those just happen |
| 38 |
to upgrade at the same time. My solution was to put those on spinning |
| 39 |
rust while using tmpfs for everything else and if needed, using |
| 40 |
--exclude to put off one or more of them then do those later. |
| 41 |
|
| 42 |
While I like the general idea of this, and would love to see emerge be |
| 43 |
able to handle it without failures, I'm not sure how emerge or it's |
| 44 |
options can prevent it without slowing down other packages. My |
| 45 |
thinking, have emerge trigger when certain packages are in the upgrade |
| 46 |
list and only allow one package in that list to update at a time. For |
| 47 |
example. If Firefox, Libreoffice and that qt package are in the list of |
| 48 |
upgrades, whichever hits first causes the others to wait until the first |
| 49 |
one is done. That will make it so only one large package is being |
| 50 |
upgraded at a time and be able to have fast settings for other smaller |
| 51 |
and less memory hungry packages as well. |
| 52 |
|
| 53 |
How to do that, I'm not a coder so no idea but I know there are some |
| 54 |
awesome coders here who may can find a way. If that idea is even |
| 55 |
something that could be done. |
| 56 |
|
| 57 |
Since I rarely post here, keep up the great work. :-D |
| 58 |
|
| 59 |
Dale |
| 60 |
|
| 61 |
:-) :-) |
Archives