Messages in this thread | | | Date | Thu, 10 Aug 2006 13:54:16 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] memory ordering in __kfifo primitives |
| |
On Thu, Aug 10, 2006 at 10:27:42PM +0200, Stelian Pop wrote: > [open-iscsi@googlegroups.com bouncing, removed from CC:] > > Le jeudi 10 août 2006 à 09:47 -0700, Paul E. McKenney a écrit : > > > > Let's take this problem differently: is a memory barrier cheaper than a > > > spinlock ? > > > > Almost always, yes. But a spinlock is cheaper than a spinlock plus > > a pair of memory barriers. > > Right, but I think we're optimizing too much here.
That was in fact my point initially -- why not just require locking, either that registered at kfifo_alloc() time or a separately acquired lock?
> > > If the answer is yes as I suspect, why should the kfifo API force the > > > user to take a spinlock ? > > > > My concern is that currently a majority of the calls to __kfifo_{get,put}() > > are already holding a spinlock. > > > > But if you could send me your tests for lock-free __kfifo_{get,put}(), > > I would be happy to run them on weak-memory-consistency model machines > > with the memory barriers. And without the memory barriers -- we need > > a test that fails in the latter case to prove that the memory barriers > > really are in the right place and that all of them are present. > > > > Does this sound reasonable? > > It would sound reasonable if I had any tests to send to you :) > > Since I don't have any and since you're the one proposing the change, I > guess it's up to you to write them. :)
Ah, but you owe a test debt from your earlier submission of kfifo! ;-)
Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |