Date: Mon, 08 Jan 2024 17:36:56 +0000 From: Thomas Sparrevohn <Thomas.Sparrevohn@me.com> To: Kyle Evans <kevans@FreeBSD.org>, <freebsd-arm@freebsd.org> Subject: Re: Freebsd on M1 Macs Message-ID: <EA4B9A45-EE8F-405D-B53F-7B76FD268BDC@me.com> In-Reply-To: <3651f45a-a96a-4816-b8fe-5e239e08af22@FreeBSD.org> References: <7a13c63d-a50b-429c-a481-0693e9faaf6b@gmail.com> <1536d845-9073-4f9b-96f6-fa9647536c00@gmail.com> <3651f45a-a96a-4816-b8fe-5e239e08af22@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
As I said to Joe in a previous post - I am personally quite impressed of ho= w easy it was go get up and running - granted it crashes with >8 Cores - but= Under parallels it ran well - making a very long term BSD user very very ha= ppy - Looking at both Linux and NetBSD - (NetBSD randomly freezes with >8 Co= res) but both seems doggy when it comes to how it handles efficiency cores. = What got me to go back to FreeBSD - was=20 A) I really miss it but since I got rid of my PC's there seems to be no opt= ion B) I do understand the codebase=20 C) Nobody seems to have a consistent approach to scheduling=20 E.g. Mac OS X uses QoS to control affinity, everybody else uses "affinity" = - but "setaffinity" seems like taking a hammer to the schedular - So I wante= d to understand. ARM as such is a bit of a mess in as much there are a very = varied number of CPU and designs - but at the same time this is why ARM is s= uch an interesting design. But Personally I am still a bit unsure what acron= ym or branding covers platform. Looking at two different - if somewhat exot= ic applications - E.g. A mainframe emulator and GNU APL who both hard relies= on the assumption that binding to a specific CPU will give you the best per= formance, personally I think that assumption is the intellectually the same = as running everything under rtprio - it seems that assumptions are being = made in the wild that will break once you have asymmetric CPU's - So I think= we - I mean the FreeBSD camp - has some work to do - If POSIX or others co= dify the state of "Now" we end up with the same mess as pthreads ended up be= ing.=20 After all that I really wanted to thank everybody who has worked on ARM for= allowing me to get back to having FreeBSD running on my daily workhorse - i= t's really a work well done Regards Thomas =20 =EF=BB=BFOn 26/11/2023, 23:52, "Kyle Evans" <owner-freebsd-arm@freebsd.org <mailt= o:owner-freebsd-arm@freebsd.org> on behalf of kevans@FreeBSD.org <mailto:kev= ans@FreeBSD.org>> wrote: On 11/26/23 16:04, Jason Bacon wrote: > On 11/26/23 13:22, Joe B wrote: >> >> I know this is a longshot but I'm going to ask I know MacOS is a BSD=20 >> but we all know it's very sugarcoated and doesn't look like a BSD. >> >> Question will real freeBSD ever come to the m1 Mac's. I got a 16 inch=20 >> mbp with good specs just taking up space right now >> >> Thanks >> >> ~ Joe B >=20 > I assume you've seen https://wiki.freebsd.org/AppleSilicon <https://wiki.= freebsd.org/AppleSilicon>. Not sure=20 > how up-to-date it is. The wikis tend to lag behind reality in my=20 > experience. >=20 Yeah, this is a bit out of date. SMP and watchdog bits are good, along=20 with some subset of the USB ports (IOMMU is a WIP). With the branch I'm=20 working on right now, we can go full multi-user on a USB root. Work stalled for a bit because there was a general disagreement with how we=20 integrated parts of the interrupt control into the interrupt framework,=20 but I've been given a vision recently of a clear path forward, so=20 hopefully we can move forward with that and unblock upstreaming some of=20 the other bits. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA4B9A45-EE8F-405D-B53F-7B76FD268BDC>