Experimental Physics and
Industrial Control System

Till Straumann <[email protected]> · Fri, 29 Jan 2016 18:00:28 -0800

On 01/29/2016 03:04 PM, J. Lewis Muir wrote:

On 1/29/16 3:54 PM, Till Straumann wrote:

These would be my arguments:

- it doesn't make much sense to use RT scheduling w/o memory locking
   as this would hurt determinism. Thus, selectively disabling
   mlockall() is a poor work-around.

Hi, Till.

True, but I think that just means the toggle is for the wrong thing.
It sounds like there should be a toggle for RT, not mlockall.  The RT
toggle would enable both the RT scheduling and the mlockall.

That's what I suggested as an alternative - if you made it all the way to
the bottom of my post ;-). I can see the value of a switch (or envvar)
- but that should control the choice of scheduler together with mlock
(and maybe even other features - such as priority inheritance - which
could be desirable on certain platforms).
The semantics should be "run as a RT app yes or no" with the default
being "no"...

- the code uses these features (RT scheduling + mlockall) *only*
   if you give it sufficient privilege to use them. If it has the
   privileges then the code assumes you want it to use them.

This is perhaps the real issue: the code assumes it should use
something just because it has sufficient privileges to do so.  If I'm
understanding things correctly, if I want to run something as root (or
with certain capabilities) *without* RT, I can't do it.  But a toggle
for RT would allow me to do it.

Regards,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System