Re: Graph of the FreeBSD memory fragmentation
Hi Alex, No, i can't comment on the C code or it's change impact otherwise. But the graphs are impressive, i say lets try it. I can test i 14-stable. Ty. On Tue, May 7, 2024 at 8:03 AM Alexander Leidinger wrote: > Hi, > > I created some graphs of the memory fragmentation. > > > https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/ > > My goal was not comparing a specific change on a given benchmark, but to > "have something which visualizes memory fragmentation". As part of that, > Bojans commit > > https://cgit.freebsd.org/src/commit/?id=7a79d066976149349ecb90240d02eed0c4268737 > was just in the middle of my data collection. I have the impression that > it made a positive difference in my non deterministic workload. > > Is there anything which prevents https://reviews.freebsd.org/D40575 to > be committed? > > Maybe some other people want to have a look at the memory fragmentation > and some of Bojans work > ( > https://wiki.freebsd.org/SummerOfCode2023Projects/PhysicalMemoryAntiFragmentationMechanisms > ). > > Bye, > Alexander. > > -- > http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF >
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]
On 2024-05-08 23:53:57 (+0800), Mark Millard wrote: On Apr 29, 2024, at 20:16, Mark Millard wrote: On Apr 29, 2024, at 20:11, Mark Millard wrote: On Apr 29, 2024, at 19:54, Mark Millard wrote: On Apr 28, 2024, at 18:06, Philip Paeps wrote: On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: On Apr 18, 2024, at 08:02, Mark Millard wrote: void wrote on Date: Thu, 18 Apr 2024 14:08:36 UTC : Not sure where to post this.. The last bulk build for arm64 appears to have happened around mid-March on ampere2. Is it broken? main-armv7 building is broken and the last completed build was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It gets stuck making no progress until manually forced to stop, which leads to huge elapsed times for the incomplete builds: [...] My guess is that FreeBSD has something that broken after bd45bbe440 that was broken as of f5f08e41aa and was still broken at 75464941dc . One thing of possible note: Failing . . . Host OSVERSION: 156 Jail OSVERSION: 1500014 I have finished a package builder refresh this morning. All our builder hosts (except PowerPC - I don't touch those) are now on main-n269671-feabaf8d5389 (OSVERSION 1500018). ampere1 successfully finished its 140releng-armv7-quarterly build, so it looks like the problem with stuck builds was limited to ampere2 building main-armv7. I'll keep a close eye on this one when it starts its next build. I see that main-armv7 started. It queued only 31935 instead of the prior 34528 (or more): it is doing an incremental build instead of a full build. For example, pkg was not built but instead the prior build is in use. Thus bad results from the prior build might be involved in this new build. I'd recommend forcing a full "poudriere bulk -c -a" that does a from-scratch build for the purposes of the main-armv7 test. Actually the test is not going to previde the information we are after as things are. giflib-5.2.2 failed to build, which leads to devel/doxygen being skipped. devel/doxygen was the first one to hang up in the prior 2 failing attempts, if I remember right. giflib-5.2.2 also causes graphics/graphviz to be skipped. graphics/graphviz was installed just before the hangup in all of the example hanups. So the context will not be replicated. We need graphics/giflib to build to actually do the test. Looks like: https://cgit.freebsd.org/ports/commit/graphics/giflib?id=5007109903fc271e3ef0ba01d78781c1fed99f3f is the fix for the graphic/giflib build failure. Well, main-armv7 is building again and things are still getting stuck. So much for my idea. For reference I list the over 10-hr-so-far ones: doxygen-1.9.6_1,2 build-depends 13:03:54 py39-pydot-2.0.0run-depends 12:24:04 py39-pygraphviz-1.6 lib-depends 12:10:38 "ps -alxdww" would likely be appropriate to get a copy of the otuput of. "procstat -k -k" usage and the like on stuck processes would probably be appropriate. Does anyone with appropriate investigative background have login access to ampere2 to take a look at what is getting stuck? This is unfortunate. I'm sure I have the appropriate background, but I'm spread very thin! I'll get as much information as I can about this machine while it's stuck, before I bounce it again. I think it may be worth a try building those ports in isolation on ref14-aarch64, and see what they're trying to do. I'll also set up a set of refX-armv7 jails on that machine. Hopefully we can get to the bottom of this soon. This is a very tedious failure mode. We could also try to put an older armv7 image on the builder jail on ampere2. Depending on whether we have a sufficiently old image, that will either be very straightforward, or a very deep rabbit hole. Thanks again for keeping an eye on this. We really should have better monitoring for stuck builds than "Mark will tell us". :-) Philip
Re: Graph of the FreeBSD memory fragmentation
Hi, On 5/7/24 14:02, Alexander Leidinger wrote: Hi, I created some graphs of the memory fragmentation. https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/ My goal was not comparing a specific change on a given benchmark, but to "have something which visualizes memory fragmentation". As part of that, Bojans commit https://cgit.freebsd.org/src/commit/?id=7a79d066976149349ecb90240d02eed0c4268737 was just in the middle of my data collection. I have the impression that it made a positive difference in my non deterministic workload. Thank you for working on this, the plots look great! They provide a really clean visual overview of what's happening. I'm working on another type of memory visualization which might interest you, I'll share it with you once its done. One small nit - the fragmentation index does not quantify fragmentation for UMA buckets, but for page allocator freelists. Is there anything which prevents https://reviews.freebsd.org/D40575 to be committed? D40575 is closely tied to the compaction patch (D40772) which is currently on hold until another issue is solved (see D45046 and related revisions for more details). I didn't consider landing D40575 because of that, but I guess it could be useful on its own. Bojan
Re: pkg server for current/arm64 stopped ? [main-armv7 on ampere2, . . .] [Update to Host OSVERSION 1500018 did not help]
On Apr 29, 2024, at 20:16, Mark Millard wrote: > On Apr 29, 2024, at 20:11, Mark Millard wrote: > >> On Apr 29, 2024, at 19:54, Mark Millard wrote: >> >>> On Apr 28, 2024, at 18:06, Philip Paeps wrote: >>> On 2024-04-18 23:14:22 (+0800), Mark Millard wrote: > On Apr 18, 2024, at 08:02, Mark Millard wrote: >> void wrote on >> Date: Thu, 18 Apr 2024 14:08:36 UTC : >> >>> Not sure where to post this.. >>> >>> The last bulk build for arm64 appears to have happened around >>> mid-March on ampere2. Is it broken? >> >> main-armv7 building is broken and the last completed build >> was the one started on Mon, 19 Feb 2024 12:32:10 GMT. It >> gets stuck making no progress until manually forced to stop, >> which leads to huge elapsed times for the incomplete builds: >> >> [...] >> >> My guess is that FreeBSD has something that broken after bd45bbe440 >> that was broken as of f5f08e41aa and was still broken at 75464941dc . >> > > One thing of possible note: > > Failing . . . > > Host OSVERSION: 156 > Jail OSVERSION: 1500014 I have finished a package builder refresh this morning. All our builder hosts (except PowerPC - I don't touch those) are now on main-n269671-feabaf8d5389 (OSVERSION 1500018). ampere1 successfully finished its 140releng-armv7-quarterly build, so it looks like the problem with stuck builds was limited to ampere2 building main-armv7. I'll keep a close eye on this one when it starts its next build. >>> >>> I see that main-armv7 started. >>> >>> It queued only 31935 instead of the prior 34528 (or more): it is doing an >>> incremental build instead of a full build. For example, pkg was not built >>> but instead the prior build is in use. Thus bad results from the prior >>> build might be involved in this new build. >>> >>> I'd recommend forcing a full "poudriere bulk -c -a" that does a from-scratch >>> build for the purposes of the main-armv7 test. >> >> Actually the test is not going to previde the information we are >> after as things are. >> >> giflib-5.2.2 failed to build, which leads to devel/doxygen being >> skipped. devel/doxygen was the first one to hang up in the prior >> 2 failing attempts, if I remember right. >> >> giflib-5.2.2 also causes graphics/graphviz to be skipped. >> graphics/graphviz was installed just before the hangup in all of >> the example hanups. So the context will not be replicated. >> >> We need graphics/giflib to build to actually do the test. > > Looks like: > > https://cgit.freebsd.org/ports/commit/graphics/giflib?id=5007109903fc271e3ef0ba01d78781c1fed99f3f > > is the fix for the graphic/giflib build failure. Well, main-armv7 is building again and things are still getting stuck. So much for my idea. For reference I list the over 10-hr-so-far ones: doxygen-1.9.6_1,2 build-depends 13:03:54 py39-pydot-2.0.0run-depends 12:24:04 py39-pygraphviz-1.6 lib-depends 12:10:38 "ps -alxdww" would likely be appropriate to get a copy of the otuput of. "procstat -k -k" usage and the like on stuck processes would probably be appropriate. Does anyone with appropriate investigative background have login access to ampere2 to take a look at what is getting stuck? === Mark Millard marklmi at yahoo.com
