| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 <2019> 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: EPICS 3.15 mlockall()/dbThreadRealtimeLock high memory usage |
| From: | Till Straumann via Tech-talk <[email protected]> |
| To: | Lucas Russo <[email protected]>, EPICS Tech Talk <[email protected]> |
| Date: | Wed, 24 Jul 2019 10:53:39 -0700 |
|
EPICS IOCs traditionally (back in the
days when most of them were running on vxWorks)
have been supporting or even relying on real-time scheduling. This is also true under linux. However, real-time scheduling doesn't make much sense if memory has to be paged in before RT threads can do their work. Thus the need to lock pages in memory. Under linux the IOC attempts to use RT scheduling and if it is allowed to use the RT scheduler then it also attempts to mlockall(). The mechanism to prevent an IOC from using these mechanisms is simple: restrict the processes' privileges to use RT priorities and it will execute as a non-RT process and will in this case not try to mlockall(). On most linux distros a normal process lacks the privilege to use RT - the sysadmin has to specifically set this up so select processes may use RT. If your system is very relaxed or you run IOCs as root then you have to revoke privileges (ulimit) from processes that should not use RT. Since these are administrative decisions and can be managed with ordinary linux sysadmin tools there is no need for special EPICS mechanisms. See also: https://wiki-ext.aps.anl.gov/epics/index.php/How_To_Use_Posix_Thread_Priority_Scheduling_under_Linux HTH - Till On 7/24/19 10:24 AM, Lucas Russo via Tech-talk wrote:
|