Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Mon, 23 Nov 2015 17:41:21 -0500

On 11/23/2015 05:17 PM, Andrew Johnson wrote:
> Hi Ralph,
>
> On 11/23/2015 03:54 PM, Ralph Lange wrote:
>> ...
>> I guess we never thought about this memlocking thing being done when
>> you start a client on a real-time system. Doesn't make much sense to
>> memlock, but running a client on a real-time system is certainly
>> legal.
> I was never completely happy with this mlockall() solution but didn't
> really know why until now.

I'm not a huge fan of doing this by default, even for IOCs.  I can't
cite any specific bad behavior, but I think the potential for surprises
is there, especially w/ MCL_FUTURE.  The closest I can come to specifics
is wondering how this mixes with the OOM killer on Linux (which is
enough fun as is).

> ...
> I think it probably makes more sense for the application itself (i.e.
> the IOC's startup script) to explicitly ask for mlockall() to be called,
> but I don't know whether we could implement that level of change in 3.15.

How about moving the call to mlockall() from once() in osdThread to
iocInit()?  Perhaps with a global variable as a conditional?  For 3.15
the default would be to call it.

This could prevent non-IOC processes from being effected.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System