Date: Mon, 10 Dec 2018 18:26:57 -0600 From: Justin Hibbits <chmeeedalf@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Warner Losh <imp@bsdimp.com>, Kevin Bowling <kevin.bowling@kev009.com>, Mateusz Guzik <mjguzik@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, scottl@freebsd.org Subject: Re: svn commit: r341682 - head/sys/sys Message-ID: <CAHSQbTA63E5iXYAkHevGr_GDNyo5-gQaFH9dxfnAvL__WfsyAQ@mail.gmail.com> In-Reply-To: <1544486233.1860.343.camel@freebsd.org> References: <201812071205.wB7C5BvA038350@repo.freebsd.org> <1544206201.1860.288.camel@freebsd.org> <CAGudoHGUqiByb37wcbhMD3eWmxFrX5=BKMiF3bk6Ptr2WWggAg@mail.gmail.com> <CAK7dMtBj26Fa-eS3WcKezjnrweDJ9RgZvBpbiRK-9S-A4Svb8Q@mail.gmail.com> <CANCZdfoXuKxuOztCU7Xoavak5b6KYB9bBQonssWUABgQabBBUQ@mail.gmail.com> <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> <1544486233.1860.343.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 10, 2018, 17:57 Ian Lepore <ian@freebsd.org wrote: > On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote: > > On 12/8/18 7:43 PM, Warner Losh wrote: > > > > > > > > > > > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling <kevin.bowling@kev009.co > > > m <mailto:kevin.bowling@kev009.com> wrote: > > > > > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik <mjguzik@gmail.co > > > m <mailto:mjguzik@gmail.com>> wrote: > > > > > > > > > > > Fully satisfying solution would be that all architectures get > > > 64-bit > > > > ops, even if in the worst case they end up taking a lock. > > > Then > > > > subsystems would not have to ifdef on anything. However, > > > there > > > > was some opposition to this proposal and I don't think this > > > is > > > > important enough to push. > > > > > > Mateusz, > > > > > > Who is opposing this particular polyfill solution? Scott Long > > > brought > > > up a situation in driver development where this would be useful > > > as > > > well. The polyfills lower the cognitive load and #ifdef soup > > > which > > > are the right call here regardless of performance on toy ports. > > > > > > > > > I don't recall seeing the opposition either. It would have to be a > > > global lock for all 64bit atomics.... but I think it would only be > > > 2 atomics on those architectures. > > It would have to be a spin lock, so in the case of unrl you would be > > trading > > an operation on one of N regular mutexes for a single spin lock that > > was > > also contested by other things. This would be pretty crappy. For > > drivers > > that aren't actually used on platforms without 32-bit atomics we can > > simply > > not build them in sys/modules/Makefile or not put them in > > GENERIC. For > > something in the core kernel like unrl I think we will have to do > > what > > Mateusz has done here. > > > > On a single-core system all you need to implement 64-bit atomics in the > kernel is to disable interrupts around using normal load/store > operations on the values. Do we have any platforms that are SMP but > don't have hardware primitives for 64-bit atomics? > > -- Ian > There were some dual processor G4 machines. I have one. It doesn't have 64 bit atomics. - Justin >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTA63E5iXYAkHevGr_GDNyo5-gQaFH9dxfnAvL__WfsyAQ>