[RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware
David Miller
davem@davemloft.net
Thu Nov 3 02:52:00 GMT 2016
From: Torvald Riegel <triegel@redhat.com>
Date: Wed, 02 Nov 2016 23:33:03 +0100
> On Wed, 2016-11-02 at 11:32 -0400, David Miller wrote:
>> From: Torvald Riegel <triegel@redhat.com>
>> > Or do you intend to write sparc-specific versions of all the concurrent
>> > data structures that are process-shared?
>>
>> This would be necessary anyways, if we have two modes. One that does
>> the pure-userland code path and one that does the kernel helper code
>> path.
>
> All the other archs that use a kernel helper for CAS don't need it. If
> you can call the helper in the atomic operations, you won't need a new
> algorithm except if you wanted to optimize the generic one.
>
>> Furthermore, sparc specific versions are needed in any case since we
>> have the v9 detection even in the v8 libraries. Look at all of the
>> code that checks for v9 in the dl_hwcap mask when deciding which
>> atomic operation to use.
>
> Or are you talking about the implementation of the atomic operations?
Just as the "are we running on a v9 chip" test is a run-time one,
whether we are running on a kernel with kernel CAS simulation support
will be run time code path check as well.
This is why we'll need sparc specific versions of the primitives, and
why it would have been the more optimal if the primitives were
abstracted to the point where we didn't have to duplicate so much
stuff privately just to pull this off.
More information about the Libc-alpha
mailing list