Re: [PATCH v2 08/11] firewire-sbp-target: Add sbp_login.{c,h}

[Paul E. McKenney]

On Sat, Mar 03, 2012 at 06:37:22PM +0100, Stefan Richter wrote:
> On Feb 16 Chris Boot wrote:

[ . . . ]

> > I guess I need to protect access to 
> > the entire session really. Possibly even rwlocks due to only the 
> > management processes ever changing anything, but lots of reads during 
> > command handling.
> 
> The use case for rwlocks is not really the case where infrequent write
> access meets frequent read access.  Rather, the use case is when it is
> important to reduce or prevent contention between readers.
> 
> Rwlocks come with their own downsides though.  I guess the somewhat
> costlier lock implementation could counter the benefit of allowing
> concurrent readers.  Or maybe latency spikes around a write access could be
> an issue.
> 
> I believe I have read somewhere that one should rather use a simple
> spinlock unless exhaustive tests prove that an rwlock really performs
> better.  Furthermore, in many if not all use cases of rwlocks, RCU is
> available as another alternative.  RCU comes with its own set of downsides
> though, for example not being as well and widely understood by programmers
> compared to locking, being less easy to debug (may have improved
> recently), and posing some challenges to RT-PREEMPT kernels.

The preemptible RCU implementations (TREE_PREEMPT_RCU and TINY_PREEMPT_RCU)
handle the -rt tree.

> AFAIU the above considerations cannot be applied 100 % to able-to-sleep
> reader-writer locks, i.e. the kernel's rwsem.  Still, the use case of an
> rwsem (in contrast to a mutex) is not particularly where a datum is rarely
> written and often read, but where it is desirable to let multiple readers
> not block each other.
> 
> [Somebody correct me where I'm wrong.]

And you can use SRCU if readers need to block.

That said, even I agree that RCU is not always the right tool for the job.

							;-), Paul

> PS, I cloned your git tree not long ago, but again various distractions
> kept me from having a broader look at your code...
> -- 
> Stefan Richter
> -=====-===-- --== ---==
> http://arcgraph.de/sr/
> --
> 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/
> 

--
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/