void <void_at_f-m.fm> wrote on
Date: Sat, 18 Oct 2025 12:43:07 UTC :
> On Fri, Oct 17, 2025 at 09:21:06PM -0700, Mark Millard wrote:
> >
> >At this point stable/15 and a non-debug main 16 are not all that
> >different. So I attempted builds of what I had for a ports tree
> >(from Oct 13) and then updating the ports tree and rebuilding
> >what changed ( PKG_NO_VERSION_FOR_DEPS=yes style ) based on my
> >normal environment and poudriere-devel use.
> >
> >Neither failed.
> >
> >But you give little configuration information so I do not
> >know how well my attempt approximated your context:
>
> Point taken but at that stage I only wanted to know if others
> could build it, because I couldnt on multiple poudrieres and
> it had/has not yet (2025.10.18-1224 UTC) been built on the pkg cluster.
> Now that I know it can be built, I partially know where to look, and
> I avoid making a PR for the port.
Do you use anything like:
# Delay when persistent low free RAM leads to
# Out Of Memory killing of processes:
vm.pageout_oom_seq=120
Or:
#
# For plunty of swap/paging space (will not
# run out), avoid pageout delays leading to
# Out Of Memory killing of processes:
#vm.pfault_oom_attempts=-1
#
# For possibly insufficient swap/paging space
# (might run out), increase the pageout delay
# that leads to Out Of Memory killing of
# processes (showing defaults at the time):
#vm.pfault_oom_attempts= 3
#vm.pfault_oom_wait= 10
(Mine are in /boot/loader.conf .)
> >RAM+SWAP == ??? + ??? == ???
> 128+4 == 132GB
Note that with USE_TMPFS=all but TMPFS_BLACKLIST extensively
used to avoid tmpfs use for port-packakge with huge file
system requirements, I reported for the initial build:
QUOTE
So: Somewhere between 132624 MiBytes and 143875 MiBytes or
so was sufficient RAM+SWAP, all RAM here.
END QUOTE
But that was for 32 FreeBSD cpus, not 20. Still, the file
system usage contribution to RAM+SWAP usage for when tmpfs
is in full use tends to not be all that dependent on the
FreeBSD cpu count.
Converting my figures to GiBytes:
132624 MiBytes is a little under 129.6 GiBytes
143875 MiBytes is a little under 140.6 GiBytes
The range is that wide based, in part, on
lack of significant memory pressure, given the
192 GiByes of RAM. When SWAP is is significantly
involved gives much better information about
RAM+SWAP requirements because of the memory
pressure consequences. So I'd not infer that
much from the above.
I can boot the system using hw.physmem="128G"
in /boot/loader.conf. I'll probably get a SWAP
binding warning about 512 GiBytes of SWAP
being a potential mistuning for that amount of
RAM. (More like 474 GiBytes of SWAP would likely
not complain for 128 GiBytes of RAM.)
I can disable my TMPFS_BLACKLIST list.
I can constrain to use of PARALLEL_JOBS=20 and
have MAKE_JOBS_NUMBER_LIMIT=20 for
ALLOW_MAKE_JOBS use. But attempting to have it
actually avoid 12 of the 32 FreeBSD cpus would
probably be messier and I've no experience with
any known-effective way of doing that for bulk
runs. So I may well not deal that issue and
just let it use up to the 32. This makes
judging load average implications dependent
on the 32.
Also, this build would not have prior builds
of some of the port-packages. (Nothing would
end up with "inspected" status.)
So I may later have better information for
comparison, including for RAM+SWAP use.
> The problem happened on two systems. For simplicity I'm talking about the
> beefier system. It has 20 cpu (40 with HT on but it is turned off)
> and 128GB ram. configured swap is 4GB and hardly used.
>
> >poudriere.conf :
> >USE_TMPFS=???
> all
>
> >TMPFS_BLACKLIST=???
> not defined
>
> >PARALLEL_JOBS=??? # (or command line control of such)
> 1 in poudriere.conf at the moment. It usually has 3 as per pkg.f.o
> but -J20 was also tried directly on the command line
>
> >ALLOW_MAKE_JOBS=??? # (defined vs. not)
> yes
>
> >ALLOW_MAKE_JOBS_PACKAGES=???
> undefined
>
> >MUTUALLY_EXCLUSIVE_BUILD_PACKAGES=???
> "llvm* rust* gcc*"
>
> >PRIORITY_BOOST=???
> undefined
>
> >other relevant possibilities?
> >
> >make.conf (or command line control of such):
> >MAKE_JOBS_NUMBER_LIMIT=??? # or MAKE_JOBS_NUMBER=???
> not defined within jailname-make.conf
>
> >Details for my context . . .
>
> Thank you for your time in this. I'm interested - do you
> make available your hacked version of top? Could be useful!
I'll deal with top separately. I've not been doing
source based activities for months and likely
should get my context for such up to date first.
===
Mark Millard
marklmi at yahoo.com
