Re: spinaphore conceptual draft

[Paul E. McKenney]

On Mon, May 30, 2005 at 03:39:04PM -0400, Kyle Moffett wrote:
> On May 30, 2005, at 15:28:26, Andi Kleen wrote:
> >On Mon, May 30, 2005 at 02:04:36PM -0400, Kyle Moffett wrote:
> >>The idea behind these locks is for bigger systems (8-way or more) for
> >>heavily contended locks (say 32 threads doing write() on the same  
> >>fd).
> >
> >Didn't Dipankar & co just fix that with their latest RCU patchkit?
> >(assuming you mean the FD locks)
> 
> That's lock-free FD lookup (open, close, and read/write to a certain
> extent).  I'm handling something more like serialization on a fifo
> accessed in both user context and interrupt context, which in a
> traditional implementation would use a spinlock, but with a spinaphore,
> one could do this:
> 
> In interrupt context:
> 
> spinaphore_lock_atomic(&fifo->sph);
> put_stuff_in_fifo(fifo,stuff);
> spinaphore_unlock(&fifo->sph);
> 
> In user context:
> 
> spinaphore_lock(&fifo->sph);
> put_stuff_in_fifo(fifo,stuff);
> spinaphore_unlock(&fifo->sph);
> 
> If there are multiple devices generating interrupts to put stuff in the
> fifo and multiple processes also trying to put stuff in the fifo, all
> bursting on different CPUs, then the fifo lock would be heavily loaded.
> If the system had other things it could be doing while waiting for the
> FIFO to become available, then it should be able to do those.

If you have lots of concurrent writes, then ordering cannot be guaranteed,
right?  If ordering cannot be guaranteed, why not split the fifo into
multiple parallel streams, and have the writers randomly select one
of the streams?

If a given writer's data must be ordered, one could hash based on the
task-struct pointer for processes, and any convenient pointer for
interrupt context.

That way, you decrease the contention, greatly reducing the spinning and
the context switches.

Or am I missing something here?

							Thanx, Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/