Re: www/chromium 148.0.7778.96 compile failure on 14.3-RELEASE-p11

On 5/9/26 16:40, Bugs Beastie wrote:
> May 9, 2026 22:35:11 Mark Millard <[email protected]>:
> 
>> On 5/9/26 12:35, Mark Millard wrote:
>>> On 5/9/26 08:00, Bugs Beastie wrote:
>>>> May 9, 2026 14:52:53 George Mitchell <[email protected]>:
>>>>
>>>>> On 5/9/26 08:47, George Mitchell wrote:
>>>>>> On 5/8/26 16:08, George Mitchell wrote:
>>>>>>> …
>>>>>> Build log available at https://m5p.com/~george/typescript.xz
>>>>>> There's an unhelpful "FAILED" message at line 54473.  It's not at all
>>>>>> clear to me exactly what failed.                              -- George
>>>>> Found this in my system log:
>>>>>
>>>>> May  8 19:45:25 sullivan kernel: swap_pager: out of swap space
>>>>> May  8 19:45:25 sullivan kernel: swp_pager_getswapspace(2): failed
>>>>> May  8 20:04:10 sullivan kernel: swp_pager_getswapspace(3): failed
>>>>> May  8 20:04:12 sullivan kernel: swp_pager_getswapspace(13): failed
>>>>> May  8 20:04:20 sullivan kernel: pid 40641 (clang-22), jid 0, uid 0, was killed: failed to reclaim memory
>>>>> May  8 20:04:21 sullivan kernel: pid 40645 (clang-22), jid 0, uid 0, was killed: failed to reclaim memory
>>>>> May  8 20:04:22 sullivan kernel: pid 40643 (clang-22), jid 0, uid 0, was killed: failed to reclaim memory
>>>>>
>>>>> But it's hard to believe.  I've never run out of swap space on this
>>>>> machine before.                                          -- George
>>>>
>>>> Hi!
>>>>
>>>> From my experience safe level is 64 Gb of virtual space (RAM+SWAP) for the build of (ungoogled-)chromium with 4 build threads (-j4).
>>>
>>> For what assignment of USE_TMPFS= ? tmpfs competes for RAM+SWAP.
>>>
> Hi!

Hello.

> 
> Ok, I have a quite old desktop doing desktop applications builds, it is i5-3550 quad core at 3.3GHz with 16Gb RAM (from 2013?).

So, SWAP=4*RAM. You probably get notices when the SWAP mounts warning of
a potential miss-tuning, something like (extra line wrapping happens below):

warning: total configured swap (??? pages) exceeds maximum recommended
amount (??? pages).
warning: increase kern.maxswzone or reduce amount of swap.

If anything happens that leaves you wondering if that is involved for a
problem, a somewhat smaller multiplier for a 64-bit environment avoids
the notices, providing something you could test. I've used 3.6 to 3.8
without issue, so RAM+SWAP == 4.?*RAM. In my original testing I found
that the exact bounds move around some from FreeBSD OS update to FreeBSD
OS update and I have avoided having such issues show up by not getting
close to anything that I'd observed to produce the notices. But that was
between 3.8 and 4.0 for the multiplier.

I mostly do this just because I do not have a good understanding of the
tradeoffs involved for other ways of handling it. If I understand right,
adjusting kern.maxswzone trades off some other kernel memory categories
that I do not understand how to make reasonable tradeoffs for. Judgments
relative to workload would likely be involved, so a fair amount of detail.

[32-bit environments (such as armv7) need much smaller multipliers to
avoid the notices, getting the notices someplace between 1.7 and 2.0 for
the multiplier, as I remember.]

> 
> I have enabled only 1 builder in poudriere PARALLEL_JOBS=1, but with ALLOW_MAKE_JOBS=yes.
> The tmpfs is set to USE_TMPFS=yes (wrkdir and data), but all ports that take more then 30 minutes to build are in TMPFS_BLACKLIST (plus known data blobs like TeX Live).
> 
> I have seen that most of the time goes into heavy ports that are building internally in parallel (make jobs), so 1 builder with parallel jobs works best for me.
> 
> For 2054 selected ports with deps it takes 10 days, 1 day 10 hours for ungoogled-chromium, 1 day for electron, and few days cumulative for qt-webengine, webkit (2 ports), and 4 llvm + 1 rust compilers.
> 
> The firefox at ~2.5 hours is amazing compared to the above! WTF they put there? :facepalm:

I think your notes help make clear what RAM+SWAP == 64 GiBytes means in
contexts like yours. That should help.

> 
>>> Last that I sampled an example of a USE_TMPFS=all chromium builder in
>>> poudriere-devel of the time was of chromium-137.0.7151.119:
>>>
>>> Total peak tmpfs: 43.00 GiB (there are multiple tmpfs mounts involved)
>>> usr/local/ tmpfs:  4.43 GiB
>>>
>>> Those are independent of MAKE_JOBS_NUMBER_LIMIT (or analgous) for
>>> ALLOW_MAKE_JOBS use. Other builders would have their own tmpfs use over
>>> the same time.
>>>
>>> As stands, an builder waiting for a jobs to work on holds on to its
>>> prior tmpfs use for the prior job until it is started or deleted.
>>>
>>> Last that I sampled the Total tmpfs use for chromium builder with
>>> chromium in TMPFS_BLACKLIST was for: chromium-124.0.6367.60
>>> (I did not separately also look up usr/local/ back then):
>>>
>>> 8.06 GiB
>>
>> Actually, I do still have the more recent info for such TMPFS_BLACKLIST
>> restricted tmpfs use for: chromium-137.0.7151.119 (again),
>>
>> Total peak tmpfs: 12.72 GiB
>> usr/local/ tmpfs:  4.42 GiB
>>
> I have not watched the peaks, just added 48Gb of swap and "it works" now. Swap is not in use most of the time, i think it peaks at final link operations.
> Just happy that it works somehow at all! :)
> 
>>>
>>> Being in TMPFS_BLACKLIST does not eliminate all the tmpfs use by the
>>> builder.
>>>
>>>>
>>>> HTH
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> ===
>> Mark Millard
>> marklmi at yahoo.com
> 
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com