Date: Tue, 04 Jun 2024 14:42:01 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271826] FreeBSD is disastrously slow on a PowerMac G5, freezing at every command Message-ID: <bug-271826-227-Z6mSbyDxiW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271826-227@https.bugs.freebsd.org/bugzilla/> References: <bug-271826-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271826 --- Comment #31 from Justin Hibbits <jhibbits@FreeBSD.org> --- Comment on attachment 251202 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D251202 tbsync patch 1 All the atomic_set_*()s should really be atomic_store_*(), `atomic_set` is a bit-set (OR operation). It's incorrect in the existing code, too. It real= ly doesn't make a significant difference, since the end result is the same (cpu_done should be 0 to start with, so setting nothing doesn't change that, tb_ready should be 0 to start with, so setting 1 bit does the same thing), except in the last instance to try to clear tb_ready. In the tight loop checking if cpu_done is high enough, you don't need the a= cq barrier in there, because the thread fence occupying the loop does the same thing, and acq places the barrier after the operation, so in the same place anyway. Glad to see this patch overall works for you, though! I'm really surprised those barriers are needed, since they're not needed in the mpc85xx case, wh= ich this is derived from. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271826-227-Z6mSbyDxiW>