VIP34: Conservative map usage in shared memory

Synopsis

Instead of creating fixed-size segments, the VSM could grow and shrink segments as needed to reduce the amount of memory maps in varnishd and VSM readers.

Why

A varnishd instance creates a lot of VSM segments, ranging from a single large Log segment to a lot of small Stat segments that share another set of StatDoc segments. There is the possibility of clustered Stat segments, but in general once a segment is created, it keeps a fixed size permanently.

Growing and shrinking segments was not implemented because it didn't work well on Linux when this was first attempted (citation needed). However, on Linux again, the kernel parameter vm.max_map_count (that can be tweaked with sysctl) has a relatively low default value for large setups (many backend, many threads, many objects, etc) and this can result in an allocation failure ENOMEM even when there is a lot of unused RAM.

This lead to https://github.com/varnishcache/varnish-cache/pull/4117 to circumvent a scenario where the maps limit is reached sporadically.

How

TBD