[lkml]   [2012]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 08/11] firewire-sbp-target: Add sbp_login.{c,h}
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
> -=====-===-- --== ---==
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at

 \ /
  Last update: 2012-03-15 18:57    [W:0.078 / U:11.884 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site