svn commit: r341682 - head/sys/sys

[Warner Losh]

On Mon, Dec 10, 2018, 5:27 PM Justin Hibbits <chmeeedalf at gmail.com wrote:

>
>
> On Mon, Dec 10, 2018, 17:57 Ian Lepore <ian at 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 at kev009.co
>> > > m <mailto:kevin.bowling at kev009.com> wrote:
>> > >
>> > >     On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik <mjguzik at gmail.co
>> > > m <mailto:mjguzik at 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.
>

There is a 32 bit mips machine like this as well. For drivers it's not too
bad, but for core functions in the MI part of the kernel, all known
implementations super duper suck.

Warner

>