preempt-rt, need old style rwlocks for systemtap

preempt-rt, need old style rwlocks for systemtap

[Frank Ch. Eigler]

Hi -

It has come to my attention that the preempt-rt patch suite
deliberately defeats the potential concurrency intended by systemtap's
use of rwlocks to permit concurrent readers of various data
structures.  Since systemtap's probe handlers are all atomic,
nonblocking, nonpreemptable, it does not seem like there is any
real-time-oriented benefit in this.  What can we do to work around
this and permit reader concurrency again in preempt-rt?

- FChE

Re: preempt-rt, need old style rwlocks for systemtap

[Clark Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ch. Eigler wrote:
> Hi -
> 
> It has come to my attention that the preempt-rt patch suite
> deliberately defeats the potential concurrency intended by systemtap's
> use of rwlocks to permit concurrent readers of various data
> structures.  Since systemtap's probe handlers are all atomic,
> nonblocking, nonpreemptable, it does not seem like there is any
> real-time-oriented benefit in this.  What can we do to work around
> this and permit reader concurrency again in preempt-rt?
> 

The reason it "defeats" the concurrent behavior is that it's really complicated to
have concurrent readers with Priority Inheritance, so the initial cut of rtmutexes
serialized all lock accesses.

Steven has posted a patch for comment (with no takers yet) that implements r/w locks
with concurrent readers and PI. We've just started running it on the MRG RT kernel
with some success, but I wouldn't say that it's ready for prime time.

You're welcome to help test it though...

Clark

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgcd+gACgkQHyuj/+TTEp2JCwCg4ZhqdqHCb9SZM+zrkKcyohtL
2coAoKLyUGZnRKha5NH7UDrM1QsP5ZaE
=FQas
-----END PGP SIGNATURE-----

Re: preempt-rt, need old style rwlocks for systemtap

[Frank Ch. Eigler]

Hi -

On Sat, May 03, 2008 at 09:34:16AM -0500, Clark Williams wrote:
> [...]
> > It has come to my attention that the preempt-rt patch suite
> > deliberately defeats the potential concurrency intended by systemtap's
> > use of rwlocks to permit concurrent readers [...]

> The reason it "defeats" the concurrent behavior is that it's really
> complicated to have concurrent readers with Priority Inheritance, so
> the initial cut of rtmutexes serialized all lock accesses. [...]

Do you believe priority inheritance to be an essential property of
every use of these primitives, regardless of the nature of the
specifical critical sections being protected?  Is there no way & need
to opt out of the extra machinery?

- FChE

Re: preempt-rt, need old style rwlocks for systemtap

[Peter W. Morreale]

On Sat, 2008-05-03 at 13:16 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> On Sat, May 03, 2008 at 09:34:16AM -0500, Clark Williams wrote:
> > [...]
> > > It has come to my attention that the preempt-rt patch suite
> > > deliberately defeats the potential concurrency intended by systemtap's
> > > use of rwlocks to permit concurrent readers [...]
> 
> > The reason it "defeats" the concurrent behavior is that it's really
> > complicated to have concurrent readers with Priority Inheritance, so
> > the initial cut of rtmutexes serialized all lock accesses. [...]
> 
> Do you believe priority inheritance to be an essential property of
> every use of these primitives, regardless of the nature of the
> specifical critical sections being protected?  Is there no way & need
> to opt out of the extra machinery?
> 
> - FChE

Yes, for (at least) two reasons. And No.

Without PI the best case is indeterminate latencies.  The worst case is
deadlock.  Please read Steven's excellent description of the issues in
the Documentation directory of a kernel tree.   


Best,
-PWM


> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html