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.
Attachment:
signature.asc
Description: OpenPGP digital signature
- Replies:
- Re: Successfully locked memory using mlockAll Andrew Johnson
- References:
- Re: Successfully locked memory using mlockAll Andrew Johnson
- Navigate by Date:
- Prev:
Re: Successfully locked memory using mlockAll Andrew Johnson
- Next:
Re: Successfully locked memory using mlockAll Andrew Johnson
- 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 Andrew Johnson
- Next:
Re: Successfully locked memory using mlockAll Andrew Johnson
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|