`char control[CMSG_SPACE(sizeof(*out_cmsg_value)) + 1];` is not aligned as
cmsghdr. Accessing its member may lead to a -fsanitize=alignment failure.
Align `control` to struct cmsghdr to fix the issue.
PiperOrigin-RevId: 555951052
- Adds methods to Enter, Leave and Migrate the tasks for memory controller.
- Update the memory cgroup id when the task enters and leaves the cgroups.
PiperOrigin-RevId: 555568875
checkpoint image compression (compressio) implies additional overhead
during its operations. when gvisor restores the kernel state inflate()
algorithm requires:
- CPU to un/compress the data
- Memory blocks to store and un/compress data
memory blocks originate from the bytes.Buffers and the sync.Pool that
tries to reuse them. they are released only when the system decides it
is a good moment:
pool.go: runtime_registerPoolCleanup(poolCleanup)
in my system (and in production) it takes around 240s to get the related
memory region freed (unmapped()).
during that period of time from the image state is read and the kernel is
loaded till the moment when the `poolCleanup` is called + GC() releasing
buffers gVisor Kernel (sandbox) process holds tens and hundreds of
megabytes of anonymous memory pages (RAM) busy (allocated+reserved).
pretty much often, the memory overhead of using compression can result in x2
memory overhead in production system with checkpoints restore and +100ms
(hundreds) ms of startup latency just to uncompress the image.
our use case does not suffer from having uncompressed images on disk but
suffer from the waste of memory during startup and CPU overhead.
this patch adds flag to disable compression for containers checkpoints.
Signed-off-by: Ivan Prisyazhnyy <john.koepi@gmail.com>
If disk usage of any filesystem approaches or reaches 100%, the agent
will log its disk usage to the console, and then reboot.
PiperOrigin-RevId: 555334222
Earlier we were not initializing Container.OverlayConf for sub containers.
That field itself is a foot gun, so I removed it. Instead added it as a
function parameter to force callers to fetch a fresh config.
PiperOrigin-RevId: 553519973
task.netns is always changed from a task goroutine under task.mu.
It means that we can access it without any locks from a task goroutine
we don't need to increment a reference counter in such cases.
In all other cases, we need to take task.mu.
PiperOrigin-RevId: 552913323
TestCheckpointRestore was testing that container can be restored into
a new one (e.g. clone) - twice. Change one of the restores to use the
same identity, to test the case where the same container is being saved
and then resumed at a later time.
PiperOrigin-RevId: 552866396