Ran gVisor on a Pi 4 cluster for home IoT sandboxing. Memory overhead is real—about 120MB per sandbox vs 15MB for raw containers. On 4GB boards that limits you to ~25 isolated services before OOM kicks in. Also, syscall拦截 adds 30-40% CPU overhead on ARM. Works fine for untrusted Python scripts, but I wouldn’t run anything compute-heavy.
yeap -- compute would be nearly the same. I suspect you need some kind of I/O to make your compute useful (get input for the computation / produce output etc.) so, still, this would have a negative effect overall.
the most frustrating part with having to compile a custom kernel is the maintenance burden (packaging/updating etc.), and not the time it takes to build…
I had a similar issue with networking modules for calico (k8s cni) on both rpis and jetson boards…
well, the tricky detail here (which we do not mention in the post, our bad) is that we got the raspbian config (cp /boot/config ... .config && make oldconfig) which includes most modules, and that's why it took more.
But yeap, good point about using the -j flag, it really accelerates the build!
the simplest one (and the one we're targetting) is multi-tenant services. You want to sandbox your service so that it doesn't affect the rest of the services running.
<shameless plug> We're building a container runtime to do this, and we are comparing alternatives, that's how we got there: https://github.com/urunc-dev/urunc</shameless plug>
Ran gVisor on a Pi 4 cluster for home IoT sandboxing. Memory overhead is real—about 120MB per sandbox vs 15MB for raw containers. On 4GB boards that limits you to ~25 isolated services before OOM kicks in. Also, syscall拦截 adds 30-40% CPU overhead on ARM. Works fine for untrusted Python scripts, but I wouldn’t run anything compute-heavy.
Wouldn’t compute workloads be fine as they should not be syscall bound?
yeap -- compute would be nearly the same. I suspect you need some kind of I/O to make your compute useful (get input for the computation / produce output etc.) so, still, this would have a negative effect overall.
> Fair warning: compiling a kernel on the Pi itself takes several hours.
One nit: this should only take about 40 minutes on a Pi 5, assuming you're compiling with -j6 to use all the cores.
(Still faster to cross-compile)
That is kind of what I was thinking too, and cross-compilation is still the fastest way to build for a different target.
Using distcc networked compilation instead of cross-compiling is reasonably fast too and easier to set up if one isn't familiar with either.
the most frustrating part with having to compile a custom kernel is the maintenance burden (packaging/updating etc.), and not the time it takes to build…
I had a similar issue with networking modules for calico (k8s cni) on both rpis and jetson boards…
well, the tricky detail here (which we do not mention in the post, our bad) is that we got the raspbian config (cp /boot/config ... .config && make oldconfig) which includes most modules, and that's why it took more.
But yeap, good point about using the -j flag, it really accelerates the build!
What use-cases are there for gVisor on Raspbian, given that the target is a Raspberry Pi?
the simplest one (and the one we're targetting) is multi-tenant services. You want to sandbox your service so that it doesn't affect the rest of the services running.
<shameless plug> We're building a container runtime to do this, and we are comparing alternatives, that's how we got there: https://github.com/urunc-dev/urunc</shameless plug>