Problem
The device-emulator image's runtime memlock budget (default container value ulimit -l = 8192 KB on most hosts) is too small for the pinned buffer pools used by the proxy server and its zero-copy data path. This becomes a hard failure on any code path that allocates a non-trivial bucketed buffer; for example, the #55 4 MiB bandwidth probe throws:
exception caught in Thread proxy_listener0
reason: AlignedBufferPool: pin_fn_ failed
from csrc/backend/serialization_buffer.h:106.
The fix on the operator side is docker run --ulimit memlock=-1 ..., and this is now documented in docs/deployment.md under "Quick start with --measurement" (commit 7077777). But:
- The other Quick-start examples earlier in
deployment.md don't include the flag.
- Nothing in the
Dockerfile or make docker-build / make docker-test Makefile targets sets it.
- There's no runtime check that fails early with a friendlier error.
Suggested fix (one of, or any combination)
A — Update all documented docker run invocations in docs/deployment.md, docs/DOCKER.md, and docs/DEV_README.md to consistently include --ulimit memlock=-1.
B — Update Makefile targets (docker-test, docker-run, etc.) to pass --ulimit memlock=-1 so users using make don't hit this even once.
C — Add a runtime preflight check in ProxyEnvCfg::Initialize (or wherever the buffer pools are first allocated) that calls getrlimit(RLIMIT_MEMLOCK) and logs a LOG_WARN if it's below some sensible threshold (e.g. bandwidth_payload_bytes * 4), pointing at the deployment docs. Pure ergonomics — doesn't change behavior, just turns a cryptic pin_fn_ failed into a directed warning.
Why this matters
The current behavior (silent failure on the server listener thread mid-flight, no front-line error message) is exactly the kind of thing that costs a new contributor a half-day. Surfaced during #55 step 8; not a #55 bug but worth fixing once.
Problem
The device-emulator image's runtime memlock budget (default container value
ulimit -l= 8192 KB on most hosts) is too small for the pinned buffer pools used by the proxy server and its zero-copy data path. This becomes a hard failure on any code path that allocates a non-trivial bucketed buffer; for example, the #55 4 MiB bandwidth probe throws:from
csrc/backend/serialization_buffer.h:106.The fix on the operator side is
docker run --ulimit memlock=-1 ..., and this is now documented indocs/deployment.mdunder "Quick start with --measurement" (commit 7077777). But:deployment.mddon't include the flag.Dockerfileormake docker-build/make docker-testMakefile targets sets it.Suggested fix (one of, or any combination)
A — Update all documented
docker runinvocations indocs/deployment.md,docs/DOCKER.md, anddocs/DEV_README.mdto consistently include--ulimit memlock=-1.B — Update Makefile targets (
docker-test,docker-run, etc.) to pass--ulimit memlock=-1so users usingmakedon't hit this even once.C — Add a runtime preflight check in
ProxyEnvCfg::Initialize(or wherever the buffer pools are first allocated) that callsgetrlimit(RLIMIT_MEMLOCK)and logs aLOG_WARNif it's below some sensible threshold (e.g.bandwidth_payload_bytes * 4), pointing at the deployment docs. Pure ergonomics — doesn't change behavior, just turns a crypticpin_fn_ failedinto a directed warning.Why this matters
The current behavior (silent failure on the server listener thread mid-flight, no front-line error message) is exactly the kind of thing that costs a new contributor a half-day. Surfaced during #55 step 8; not a #55 bug but worth fixing once.