Experimental Physics and
Industrial Control System

"Jemian, Pete R." <[email protected]> · Fri, 29 Jan 2016 21:43:39 +0000

I agree

----------------------------------------------------------
  Pete R. Jemian, Ph.D.                <[email protected]>
  Beam line Controls and Data Acquisition, Group Leader
  Advanced Photon Source,   Argonne National Laboratory
  Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
     Education is the one thing for which people
        are willing to pay yet not receive.
-----------------------------------------------------------


________________________________________
From: [email protected] [[email protected]] on behalf of Mark Rivers [[email protected]]
Sent: Friday, January 29, 2016 3:07 PM
To: Johnson, Andrew N.; [email protected]
Subject: RE: set-user-id root and EPICS 3.15

I vote for the EPICS_RT_MLOCKALL run-time variable.  I would like to a have a single build of EPICS base.

SPEC is the application that started this thread.  When SPEC is installed it not plre-linked against EPICS base.  Rather one points it to the site-version of EPICS base, which is then links against.   I don't want to have one version of EPICS base with mlockall() disabled for SPEC and another version with it enabled for my IOCs.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Johnson
Sent: Friday, January 29, 2016 2:56 PM
To: [email protected]
Subject: Re: set-user-id root and EPICS 3.15

On 01/28/2016 08:43 AM, Ralph Lange wrote:
> However, this is the second time that we hear of trouble because people
> are running client applications (i.e. CA clients) in real-time context.
> In those cases, the memory locking might not be intended nor useful.
> There is no way for the OS abstraction layer (where the memlock happens)
> to know if the caller is an IOC type or a client type application.
> We already began to reconsider the automatic activation feature.

I think it would be reasonable to require those that want the mlockall()
behaviour to configure it. The main question would be whether this
should be configurable at build-time, or if it can require a run-time
setting. The simplest fix would be something like this:

=== modified file 'src/libCom/osi/os/posix/osdThread.c'

--- src/libCom/osi/os/posix/osdThread.c 2015-03-19 15:22:15 +0000
+++ src/libCom/osi/os/posix/osdThread.c 2016-01-29 20:41:08 +0000
@@ -362,7 +362,8 @@
         fprintf(stderr, "LRT: min priority: %d max priority %d\n",
             pcommonAttr->minPriority, pcommonAttr->maxPriority);
     }
-    if (pcommonAttr->maxPriority > pcommonAttr->minPriority) {
+    if (getenv("EPICS_RT_MLOCKALL") &&
+        pcommonAttr->maxPriority > pcommonAttr->minPriority) {
         status = mlockall(MCL_CURRENT | MCL_FUTURE);
         if(status) {
             fprintf(stderr, "Unable to lock the virtual address space
using mlockall\n");

That would require IOCs that need the memory locking to have set the
EPICS_RT_MLOCKALL environment variable before they are executed. A
slightly more complicated solution would allow locking to be turned on
at build-time in the configure/CONFIG_SITE_ENV file, but it could be
turned off again at run-time with an environment variable.

If you currently rely on the current mlockall() behaviour of Base and
wish to influence our decision, please speak up before we commit any
changes.

- Andrew

--
There are only two hard problems in distributed systems:
  2. Exactly-once delivery
  1. Guaranteed order of messages
  2. Exactly-once delivery
 -- Mathias Verraes




Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System