SlimVM is a lightweight VMX-based platform for gVisor that accelerates
sentry system calls by eliminating unnecessary user/kernel context
switches.
In a traditional gVisor + KVM setup, every guest syscall triggers a
full VM exit to userspace, then re-enters the kernel via a regular
syscall:
gr0 -> hr0 (vm_exit) -> hr3 (ioctl return) -> hr0 (re-invoke syscall)
SlimVM eliminates this overhead. When the guest executes a VMCALL, the
VM exits into VMX root mode where SlimVM directly invokes the host
kernel's syscall handler, then immediately resumes the guest:
gr0 -> hr0 (vmcall + direct function call)
SlimVM requires a companion kernel module that provides the /dev/slimvm
device interface. See https://github.com/antgroup/slimvm for the
kernel module and full documentation.
A sentry->host getpid microbenchmark (Xeon 6982P-C, host kernel 5.10.134)
shows the effect:
│ ns/op │ vs base │
base 82.5 1.0x
slimvm 420.9 5.1x
kvm 3566.1 43.2x
slimvm is ~8.5x faster than the kvm platform on this path. See the issue
for details.
Updates: https://github.com/google/gvisor/issues/13330
Co-developed-by: Chenggang <[email protected]>
Co-developed-by: Robin Luk <[email protected]>
Co-developed-by: Tiwei Bie <[email protected]>
Co-developed-by: Jianfeng Tan <[email protected]>
Co-developed-by: liushi.ls <[email protected]>
Co-developed-by: Yong He <[email protected]>
Co-developed-by: Aaron Lu <[email protected]>
Co-developed-by: chris.zn <[email protected]>
Co-developed-by: Lai Jiangshan <[email protected]>
Co-developed-by: Lingfu <[email protected]>
Co-developed-by: Min Le <[email protected]>
Co-developed-by: Quan Xu <[email protected]>
Co-developed-by: Zhang Haoyu <[email protected]>
Co-developed-by: Dawei Shen <[email protected]>
Signed-off-by: Tianyu Zhou <[email protected]>
The self-admittedly arbitrary threshold of 20% of alarms being sent to the main
thread was being breached. I saw a run of of ~20-23% [1]. We should allow for a
little more breathing room.
1 - https://buildkite.com/gvisor/pipeline/builds/7400
PiperOrigin-RevId: 386503482
With additional logging, the issue described by the new comment looks like:
D0518 21:28:08.416810 6777 task_signals.go:459] [ 8] Notified of signal 27
D0518 21:28:08.416852 6777 task_block.go:223] [ 8] Interrupt queued
D0518 21:28:08.417013 6777 task_run.go:250] [ 8] Switching to sentry
D0518 21:28:08.417033 6777 task_signals.go:220] [ 8] Signal 27: delivering to handler
D0518 21:28:08.417127 6777 task_run.go:248] [ 8] Switching to app
D0518 21:28:08.443765 6777 task_signals.go:519] [ 8] Refusing masked signal 27 // ED: note the ~26ms elapsed since TID 8 "switched to app"
D0518 21:28:08.443814 6777 task_signals.go:465] [ 6] Notified of group signal 27
D0518 21:28:08.443832 6777 task_block.go:223] [ 6] Interrupt queued
D0518 21:28:08.443914 6777 task_block.go:223] [ 6] Interrupt queued
D0518 21:28:08.443859 6777 task_run.go:250] [ 8] Switching to sentry
I0518 21:28:08.443936 6777 strace.go:576] [ 8] exe E rt_sigreturn()
Slow context switches on ptrace are probably due to kernel scheduling delays.
Slow context switches on KVM are less clear, so leave that bug and TODO open.
PiperOrigin-RevId: 312322782
Kernel.cpuClockTicker increments kernel.cpuClock, which tasks use as a clock to
track their CPU usage. This improves latency in the syscall path by avoid
expensive monotonic clock calls on every syscall entry/exit.
However, this timer fires every 10ms. Thus, when all tasks are idle (i.e.,
blocked or stopped), this forces a sentry wakeup every 10ms, when we may
otherwise be able to sleep until the next app-relevant event. These wakeups
cause the sentry to utilize approximately 2% CPU when the application is
otherwise idle.
Updates to clock are not strictly necessary when the app is idle, as there are
no readers of cpuClock. This commit reduces idle CPU by disabling the timer
when tasks are completely idle, and computing its effects at the next wakeup.
Rather than disabling the timer as soon as the app goes idle, we wait until the
next tick, which provides a window for short sleeps to sleep and wakeup without
doing the (relatively) expensive work of disabling and enabling the timer.
PiperOrigin-RevId: 272265822
Bump up the threshold on number of SIGALRMs received by worker
threads from 50 to 200. Even with the new threshold we still
expect that the majority of SIGALRMs are received by the
thread group leader.
PiperOrigin-RevId: 254289787
Based on the guidelines at
https://opensource.google.com/docs/releasing/authors/.
1. $ rg -l "Google LLC" | xargs sed -i 's/Google LLC.*/The gVisor Authors./'
2. Manual fixup of "Google Inc" references.
3. Add AUTHORS file. Authors may request to be added to this file.
4. Point netstack AUTHORS to gVisor AUTHORS. Drop CONTRIBUTORS.
Fixes#209
PiperOrigin-RevId: 245823212
Change-Id: I64530b24ad021a7d683137459cafc510f5ee1de9
This allows ValueOrDie() to be called on PosixErrorOr rvalues (e.g.
temporaries) holding move-only types without extraneous std::move()s.
PiperOrigin-RevId: 225098036
Change-Id: I662862e4f3562141f941845fc6e197edb27ce29b
gVisor bot