[ltt-dev] [RFC PATCH 0/7] priority-boost urcu

[Mathieu Desnoyers]

* Paolo Bonzini (pbonzini at redhat.com) wrote:
> On 08/20/2011 02:43 PM, Mathieu Desnoyers wrote:
>> Hrm, beware though that the QSBR flavor has one major difference from
>> the others: in 64-bit, it represents the G.P. as a 64-bit counter
>> (rather than as a 1-bit latch), and can afford to do only one
>> increment/waiting "phase" rather than two, because it assumes overflow
>> can never happen on 64-bit.
>>
>> We cannot use this technique with other URCU flavors because we need to
>> reserve bits to keep track of the nesting count within the reader
>> threads in the same atomically accessible integer, so we don't have a
>> full 64-bit atomically writeable G.P. snapshot value available in the
>> reader threads.
>
> Yes, I'm aware of that.  I had two alternative plans about it:
>
> 1) the QSBR files do have the code for the non-QSBR variant (for  
> 32-bit); pick one or the other based on the number of counter bits,  
> rather than based on the word size.

This would make a lot of sense.

>
> 2) do we need 2^32 nesting?  If the max. nesting count can be changed to  
> 2^8 or 2^16, non-QSBR flavors can start using the counter approach on  
> 64-bit too.

Actually, even in the MB/MEMBARRIER/SIGNAL variants, we only use 16
bits for nesting count on 32-bit architectures. The main reason for this
being that it generates slightly better code on architectures like x86
to operate on the high 16-bit registers directly rather than to do some
arithmetic including the low registers, but excluding the one bit kept
around for current g.p. phase tagging. So I think a nesting level of
2^16 is safe for 32-bit, but the question becomes: is that safe for a
64-bit architecture in any forseeable future ?

So although the 32-bit architecture stack size is really limited by its
address space, so really we should not have to expect more than 2^16
nested critical sections, the theoretical limit of 64-bit architecture
is much larger, so I'm tempted to stay on the safe side and not limit
the nesting count to values below 2^32. A stack size of 65536 seems odd,
but could actually happen someday on 64-bit.

You can call me overly meticulous (and I would agree !! ;-) ), but I
prefer to keep a safe approach with respect to liburcu.

So I'm in for approach #1. :)

Thanks!

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com