Subject: |
Re: Successfully locked memory using mlockAll |
From: |
Andrew Johnson <[email protected]> |
To: |
EPICS core-talk <[email protected]> |
Date: |
Mon, 23 Nov 2015 17:09:27 -0600 |
On 11/23/2015 04:41 PM, Michael Davidsaver wrote:
> 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
It is only tried if once() is able to use SCHED_FIFO, so it's not
quite by default, and the process also has to have CAP_IPC_LOCK for
the mlockall() to succeed.
> 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).
Agreed...
>> ... 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.
For portability the mlockall() call itself must be implemented in a
new libCom/osi routine, called say epicsThreadMLockAll(), with dummy
implementations where there's no OS-specific equivalent.
The global variable would be registered in dbCore.dbd.
> This could prevent non-IOC processes from being effected.
<pedantic>s/effected/affected/</pedantic>
- Andrew
--
Light thinks it travels faster than anything but it is wrong.
No matter how fast light travels, it finds the darkness has
always got there first, and is waiting for it.
-- Terry Pratchett, Reaper Man
- References:
- Re: Successfully locked memory using mlockAll Andrew Johnson
- Re: Successfully locked memory using mlockAll Michael Davidsaver
- Navigate by Date:
- Prev:
Re: Successfully locked memory using mlockAll Michael Davidsaver
- Next:
Jenkins build is back to normal : epics-base-3.15-win64s #190 APS Jenkins
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Successfully locked memory using mlockAll Michael Davidsaver
- Next:
Build failed in Jenkins: epics-base-3.15-win64-test #19 APS Jenkins
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|