On Sun, Apr 12, 2009 at 06:13:30PM -0700, David Miller wrote: > From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> > Date: Sun, 12 Apr 2009 10:31:08 -0700 > > > On Sun, Apr 12, 2009 at 09:34:27PM +1000, Paul Mackerras wrote: > >> Paul E. McKenney writes: > >> > >> > If the generic implementation is needed only on !SMP systems, that > >> > could work. The architectures I would be worried about include > >> > powerpc and ia64, which I believe support 32-bit SMP builds. > >> > >> 32-bit powerpc doesn't have 64-bit atomic operations and does support > >> SMP. > >> > >> What about ARM? I thought they had 32-bit SMP these days as well. > > > > Some of Steve Hemminger's recent suggestions in this thread seem to me > > to avoid this whole issue nicely. But we will see! ;-) > > I hope so. > > Eventually it seems that all of the older 32-bit SMP platforms > will be run under a bus having to execute some many "efficient" > primitives using the "hash table of spinlocks" scheme for > synchronization. Or, in some cases, per-CPU locks. It might also be that 32-bit SMP systems use stop-the-world approaches. Or that we get a variant of RCU with shorter grace periods. I don't recommend holding your breath, but I have not given up on this. For one only slightly crazy example, some of the user-level RCU variants could be adapted to in-kernel use. Some of these have sub-microsecond grace-period latencies, but also have some limitations that would make it difficult for them to replace RCU wholesale in the Linux kernel. And it is not like we are suffering from any lack of distinct RCU implementations in the Linux kernel just now. :-/ However, they might be useful in isolated situations. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
