On 15/08/2018 02:34, Emilio G. Cota wrote:
> On Tue, Aug 14, 2018 at 08:26:54 +0200, Paolo Bonzini wrote:
>> On 13/08/2018 18:38, Emilio G. Cota wrote:
>>> Fix it by implementing the CPU list as an RCU QLIST. This requires
>>> a little bit of extra work to insert CPUs at the tail of
>>> the list and to iterate over the list in reverse order (see previous patch).
>>>
>>> One might be tempted to just insert new CPUs at the head of the list.
>>> However, I think this might lead to hard-to-debug issues, since it is
>>> possible that callers are assuming that CPUs are inserted at the tail
>>> (just like spapr code did in the previous patch). So instead of auditing
>>> all callers, this patch simply keeps the old behaviour.
>>
>> Why not add an RCU_QSIMPLEQ
>
> Because we can't atomically update both head.last and item.next.
Why do you need that? Updates are protected by a mutex in RCU-protected
lists, it is not necessary to make them atomic. Also, feel free to
implement a subset of the write-side macros, for example only
INSERT_{HEAD,TAIL,AFTER} and REMOVE_HEAD.
Anyway, the only difference between non-RCU and RCU-protected update
macros should be the write barriers (atomic_rcu_set).
>> , or even use an array since the quadratic
>> behavior should not be an issue? The advantage of the array is that
>> reverse iteration becomes trivial.
>
> I just gave this a shot. IMO implementing CPU_NEXT based on the
> array is too ugly to live.
You're right, I forgot about CPU_NEXT.
Paolo
