* Paolo Bonzini ([email protected]) 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
