Date: Sun, 14 Feb 2021 09:57:02 -0600 From: "Brandon Bergren" <bdragon@FreeBSD.org> To: "FreeBSD PowerPC ML" <freebsd-ppc@freebsd.org> Subject: =?UTF-8?Q?Re:_Test_of_FreeBSD-13.0-ALPHA3-powerpc-powerpc64-20210129-40c?= =?UTF-8?Q?b0344eb2-256214-disc1.iso.xz?= Message-ID: <5e905bca-c62e-4f72-8f22-09ac384b9ae9@www.fastmail.com> In-Reply-To: <a3ab05f5-e366-cbc3-0f97-94fec4dbd550@blastwave.org> References: <8348beb1-06f4-6b65-cf62-74c81dcf31f6@blastwave.org> <a3ab05f5-e366-cbc3-0f97-94fec4dbd550@blastwave.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 14, 2021, at 12:31 AM, Dennis Clarke via freebsd-ppc wrote: > Performance is best described as terrible. I did fetch src.txz from > the releases directory : > https://download.freebsd.org/ftp/releases/powerpc/powerpc64/13.0-BETA2/ Yes, the clang compiler is known to be *much* slower than the old GCC. It's gigantic in comparison and some of the passes are a lot more computationally expensive. It's a nearly 100 meg dynamically-linked binary. > > Currently running a buildworld which appears that it will be some days > before that completes. This may actually be slower than a qemu instance > of FreeBSD-CURRENT on RISC-V. Yeah, it probably will. I don't currently test buildworld on anything older than POWER8, just because it's so much time investment to do so. > The Decrementer exception seen in December CURRENT no longer exists. > Seen here > https://beta.genunix.com/freebsd/ppc64/power_mac_quad_freebsd_13_current_17_dec_2020_fail.png Yep. That is the problem that https://cgit.freebsd.org/src/commit/sys/powerpc/aim?id=d26f2a50ff48dacd38ba358d658882d51f7bdbc4 fixes. > I want to dig into the smp issue if I can but at the moment I will await > for a full buildworld/buildkernel and then see where we are. > I believe most of the smp issue boils down to the timebase getting out of sync between processors and causing paradoxes in the scheduler. There are some algorithms there that really don't like the timebase moving backwards and it can cause stuff like scheduled timers to get lost, which manifests in processes hanging in syscalls and such. There is some background discussion in https://reviews.freebsd.org/D23376 and on the list about this. The basic solution is to rendezvous and have all processors initialize their timebase to a specific value and then wait for a broadcast from the boot processor to all enable it at the same time. Unfortunately, I have limited ability to work on this as my only SMP PowerMac is a dual G4, which works a bit differently than the G5s. Although I could certainly work on the G4 version of this problem. -- Brandon Bergren bdragon@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5e905bca-c62e-4f72-8f22-09ac384b9ae9>