From mboxrd@z Thu Jan 1 00:00:00 1970 From: rgetz@blackfin.uclinux.org (Robin Getz) Date: Fri, 13 Feb 2009 23:58:35 -0500 Subject: [ltt-dev] [Uclinux-dist-devel] [RFC git tree] Userspace RCU (urcu) for Linux (repost) In-Reply-To: References: <20090211185203.GA29852@Krystal> <20090212200249.GG6759@linux.vnet.ibm.com> Message-ID: <200902132358.36112.rgetz@blackfin.uclinux.org> On Thu 12 Feb 2009 15:13, Linus Torvalds pondered: > On Thu, 12 Feb 2009, Paul E. McKenney wrote: > > And, now that you mention it, I have heard rumors that other CPU > > families can violate cache coherence in some circumstances. > > I personally suspect that the BF pseudo-SMP code is just broken, and > that it likely has tons of subtle bugs and races - because we _do_ depend > on cache coherency at least for accessing objects next to each other. I felt similarly, however after using it, testing it, beating the crap out of it for while, and only finding a few niggly bugs which were corrected - it appears to be as stable as any other Linux kernel I have used on embedded hardware (which means rock solid). There are a few people shipping it in their products today - so at least the stablily was also good enough for them. If you have any other test suggestions which might expose the corner cases that normal use / LTP / would not - I'm happy to try it out. The problem is - as Mike stated - since we do limit applications to one core at a time - multi-threading userspace isn't really interesting a problem. As for the claim of "broken" hardware - I don't think that is true -- the hardware works as designed, as advertised. It was just never architected to run a SMP operating system. While you could claim that we are trying to force fit (SMP) something where it doesn't belong (non-cache coherence system), it is us that are "broken" - not the hardware :) -Robin