User manual

Miscellaneous Notes

temporarily serialize the system until the fault is resolved. It is not critically important to avoid

the faults, but it is desirable from the performance standpoint. VAX MP therefore tries to lock all

of its code and data in memory, including code and data of the simulator itself, code and data of

all loaded runtime libraries, thread stacks etc. VAX MP uses Linux system call

mlockall(MCL_CURRENT) to perform such locking. Depending on Linux version, this call

requires either process privilege (running as root or having capability CAP_IPC_LOCK) or

increasing RLIMIT_MEMLOCK for the account via /etc/security/limits.conf. If VAX MP does not

have sufficient privileges or resource allocation limits expanded, it will display this message.

On Linux host systems with plenty of available RAM where VAX MP does not incur paging at run

time other than initial page-in at boot time, this message is unimportant in practical terms and

does not really need a corrective action.

If VAX MP incurs paging at run time, as may be indicated by Linux system monitoring utilities, it

is desirable to enable VAX MP full working set locking in memory. To enable memory locking

privileges do either of the following:

• run VAX MP as root (e.g. via

sudo);

• grant CAP_IPC_LOCK capability to VAX MP executable file with Linux

setcap command:

sudo setcap cap_ipc_lock+eip /path/vax

• grant capability CAP_IPC_LOCK to the account or accounts used to run VAX MP and use

Linux command

chrt to launch VAX MP;

• on Linux 2.6.9 and later, add the following lines to file /etc/security/limits.conf for each

account that will be used to run VAX MP and that you want to be able to lock VAX MP

data and code in memory:

vaxuser soft memlock xxxx

vaxuser hard memlock xxxx

where xxxx denotes the amount of code and data applications executed by the account

are allowed to lock in memory, expressed in kilobytes. Note that this authorization is

per-account and allows memory locking not only by VAX MP, but also by any application

that issues memlock system calls and is executed by the account.

LOCKRETRY

VSMP LOAD command will set SYSGEN parameter LOCKRETRY to 900000 unless command

option NOPATCH=LOCKRTRY is used. Do not decrease the value of LOCKRETRY after executing

VSMP LOAD. VSMP LOAD passes the value of LOCKRETRY to the simulator’s SIMH layer which

uses passed value to compute internal control variables such as synchronization window size.

Decreasing LOCKRETRY on top of the running simulator after VSMP LOAD command will make

these pre-calculated controls invalid and can cause OpenVMS to bugcheck with BADQHDR code.