In message <ba0ce7d8-cfa1-40a3-befa-21d0c230b...@yahoo.com>, Mark Millard write s: > > > > On 2020-Jan-27, at 10:20, Cy Schubert <Cy.Schubert at cschubert.com> wrote: > > > On January 27, 2020 5:09:06 AM PST, Cy Schubert <cy.schub...@cschubert.com> > wrote: > >>> . . . > >> > >> Setting a lower arc_max at boot is unlikely to help. Rust was building > >> on > >> the 8 GB and 5 GB 4 core machines last night. It completed successfully > >> on > >> the 8 GB machine, while using 12 MB of swap. ARC was at 1307 MB. > >> > >> On the 5 GB 4 core machine the rust build died of OOM. 328 KB swap was > >> used. ARC was reported at 941 MB. arc_min on this machine is 489.2 MB. > > > > MAKE_JOBS_NUMBER=3 worked building rust on the 5 GB 4 core machine. ARC is > at 534 MB with 12 MB swap used. > > If you increase vm.pageout_oom_seq to, say, 10 times what you now use, > does MAKE_JOBS_NUMBER=4 complete --or at least go notably longer before > getting OOM behavior from the system? (The default is 12 last I checked. > So that might be what you are now using.)
It's already 4096 (default is 12). > > Have you tried also having: vm.pfault_oom_attempts="-1" (Presuming > you are not worried about actually running out of swap/page space, > or can tolerate a deadlock if it does run out.) This setting presumes > head, not release or stable. (Last I checked anyway.) Already there. The box is a sandbox with remote serial console access so deadlocks are ok. > > It would be interesting to know what difference those two settings > together might make for your context: it seems to be a good context > for testing in this area. (But you might already have set them. > If so, it would be good to report the figures in use.) > > Of course, my experiment ideas need not be your actions. It's a sandbox machine. We already know 8 GB works with 4 threads on as many cores. And, 5 GB works with 3 threads on 4 cores. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
