Whether to ensure that all required shared memory is available by
	"locking" that shared memory into RAM when Squid starts. The
	alternative is faster startup time followed by slightly slower
	performance and, if not enough RAM is actually available during
	runtime, mysterious crashes.

	SMP Squid uses many shared memory segments. These segments are
	brought into Squid memory space using an mmap(2) system call. During
	Squid startup, the mmap() call often succeeds regardless of whether
	the system has enough RAM. In general, Squid cannot tell whether the
	kernel applies this "optimistic" memory allocation policy (but
	popular modern kernels usually use it).

	Later, if Squid attempts to actually access the mapped memory
	regions beyond what the kernel is willing to allocate, the
	"optimistic" kernel simply kills Squid kid with a SIGBUS signal.
	Some of the memory limits enforced by the kernel are currently
	poorly understood: We do not know how to detect and check them. This
	option ensures that the mapped memory will be available. 

	This option may have a positive performance side-effect: Locking
	memory at start avoids runtime paging I/O. Paging slows Squid down.

	Locking memory may require a large enough RLIMIT_MEMLOCK OS limit,
	CAP_IPC_LOCK capability, or equivalent.