lkml.org 
[lkml]   [2006]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-08-10 22:57    [W:0.597 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site