[squid-dev] [PATCH] shared_memory_locking
Amos Jeffries
squid3 at treenet.co.nz
Thu Mar 10 08:33:55 UTC 2016
On 10/03/2016 11:14 a.m., Alex Rousskov wrote:
> Hello,
>
> The attached patch adds a "shared_memory_locking" configuration
> directive to control mlock(2).
>
> Locking shared memory at startup avoids SIGBUS crashes when kernel runs
> out of RAM during runtime. This has been discussed during the "[RFC] Fix
> shared memory initialization, cleanup. Ensure its usability." thread
> archived at
> http://lists.squid-cache.org/pipermail/squid-dev/2015-December/004112.html
>
> Why not enable locking by default? Unfortunately, locking requires
> privileges and/or much-higher-than-default RLIMIT_MEMLOCK limits. Thus,
> requiring locked memory by default is likely to cause too many
> complaints, especially since Squid has not required that before. Even
> "make check" will not work in most environments (without making our unit
> tests even less representative)! Thus, the default is off, at least for now.
>
> As we gain more experience, we may enable locking by default while
> making default locking failures non-fatal and warning about significant
> [accumulated] locking delays. The proposed code was written to make
> those possible future changes easier, but I am not volunteering to
> implement them at this time.
>
In Ipc::Mem::Segment::lock():
* please use #if defined() instead of #ifdef.
* fatalf() sends a FATAL level error to cache.log. No need to preceed it
with a less important debugs ERROR message saying the same thing.
Amos
More information about the squid-dev
mailing list