Re: More swap trouble with armv7, was Re: -current on armv7 stuck with flashing disk light"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 05 Jul 2023 07:04:26 UTC
bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Wed, 05 Jul 2023 01:02:31 UTC :
> On Wed, Jul 05, 2023 at 08:22:43AM +0900, Tatsuki Makino wrote:
> > Hello.
> >
> >
> > It may be possible to set stricter restrictions on selected ports in /usr/local/etc/poudriere.d/make.conf.
True. But this does not vary the number of builders that
run in parallel. That must be separately use -J1 (or an
equivalent) for Bob's RAM constrained environment.
I do not remember Bob P. reporting explicitly about the
number of builders that were active. Probably only 1,
but I'm not sure.
> > For example,
> >
> > # normally
> > .if ${.CURDIR:tA} == "/usr/ports/devel/llvm15"
> > MAKE_JOBS_NUMBER= 1
> > .endif
> >
> > # pattern matching can be performed
> > .if !empty(.CURDIR:tA:M/usr/ports/devel/llvm15) ||
> > !empty(.CURDIR:tA:M/usr/ports/devel/llvm*)
> > MAKE_JOBS_NUMBER= 1
> > .endif
> >
> > # not limited to /usr/ports
> > .if !empty(.CURDIR:tA:T:Mllvm*) && !empty(.CURDIR:tA:H:T:Mdevel)
> > MAKE_JOBS_NUMBER= 1
> > .endif
> >
> > If we write this on an individual port basis, we can use the resources to the very limit where they don't overflow :)
> >
Yep: I've got examples around, such as:
.elif ${.CURDIR:M*/editors/lapce*}
MAKE_JOBS_NUMBER=1
> I just tried to turn off parallel jobs entirely by omitting
> ALLOW_MAKE_JOBS
> from /usr/local/etc/poudriere.conf
What of the number of builders? Was this a "bulk -J1"
test?
> The machine ran out of
> swap as usual, in about the same time, despite having only
> two processes running that were visibly related to poudriere
> with a total size of ~250 MB. The number of threads roughly
> halved, but the time to swap exhaustion didn't.
I've not seen anything about the devel/llvm15
build options enabled vs. disabled.
Were you using a "bulk -J1"?
> While poudriere makes /devel/llvm15 by itself, top reports
>
> last pid: 15623; load averages: 0.88, 0.88, 0.75 up 0+00:26:27 17:39:54
> 34 processes: 2 running, 32 sleeping
> CPU: 27.9% user, 0.0% nice, 7.3% system, 0.0% interrupt, 64.8% idle
> Mem: 274M Active, 219M Inact, 177M Laundry, 221M Wired, 97M Buf, 22M Free
> Swap: 2048M Total, 1032M Used, 1016M Free, 50% Inuse
>
> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 14989 root 1 20 0 41M 25M select 2 0:10 0.01% pkg-static
> 1080 bob 1 20 0 14M 1460K select 0 0:00 0.00% sshd
> 1077 root 1 31 0 14M 1420K select 0 0:00 0.00% sshd
> 1029 root 1 23 0 13M 1600K select 1 0:00 0.00% sshd
> 1042 root 1 20 0 10M 1616K select 0 0:00 0.00% sendmail
> 14988 root 1 68 0 10M 2976K wait 0 0:00 0.00% pkg-static
> 1045 smmsp 1 68 0 10M 1344K pause 0 0:00 0.00% sendmail
> 15405 root 1 126 0 9432K 6636K CPU1 1 0:15 100.04% makewhatis
> 1081 bob 1 48 0 6852K 1016K pause 1 0:00 0.00% tcsh
> 1162 bob 1 52 0 6824K 1016K pause 3 0:00 0.00% tcsh
> 1166 bob 1 20 0 6688K 1784K CPU3 3 0:05 0.30% top
> 726 root 1 20 0 6612K 1348K select 3 0:00 0.00% devd
> 11515 root 1 68 0 6568K 2812K wait 3 0:01 0.00% make
> 1399 root 1 68 0 6212K 1712K nanslp 1 0:33 4.92% sh
> 8353 root 1 53 0 5820K 1632K piperd 0 0:00 0.00% sh
> 1099 root 1 20 0 5820K 1624K select 1 0:10 0.00% sh
> 8360 root 1 68 0 5820K 1588K wait 3 0:00 0.00% sh
> 1086 root 1 20 0 5584K 1048K ttyin 2 0:00 0.00% sh
> 11543 root 1 68 0 5480K 1548K wait 1 0:00 0.00% sh
> 1076 root 1 21 0 5424K 1120K wait 2 0:00 0.00% login
> 1085 bob 1 24 0 5380K 1116K wait 3 0:00 0.00% su
A pkg-statics process pair and a makewhatis does not
seem typical of the bulk of devel/llvm15's build
time. It is unclear to me what to make of this top
output. Having more processes than top displays
tends to limit information as well.
Ordering by "res" tends to show large active-RAM
usage processes at the top. One can have a large
SIZE process that has little RAM in active use
over a significant time.
But, with the 40 min allowed for a page fault, it
is far from clear how much space is just for
pending but in-process page fault activity.
> The SIZE numbers in relation to swap used are puzzling.
Overall SIZE gets into how to memory space RAM shared
across processes and such. There may well be other
ways in which the total of the SIZE figures is not
just a direct RAM+SWAP usage figure. Having a chunk
of memory address space identified but not all of
it allocated to RAM/SWAP may be a possibility that
could still count towards SIZE.
> Shouldn't
> swap be roughly the difference between total of SIZE minus total of RES?
No, for example multi-counting of shared memory/RAM.
> That's not the case, unless my eyeball math is way off.
Not the case: your eyeball math is working.
> The poudriere run just failed, in the same way as before, with 1228 MB
> of swap in use.
So, some of the 177M of laundry may have been
written out to swap space. (One of many
possibilities for what might have contributed.)
> It's tempting to try running make in /usr/ports/devel/llvm15, just
> to see if there's a difference in behavior.
Was poudriere running only one builder?
===
Mark Millard
marklmi at yahoo.com