diff options
| -rw-r--r-- | content/docs/architecture_guide/performance.md | 39 | ||||
| -rw-r--r-- | content/docs/user_guide/FAQ.md | 4 |
2 files changed, 0 insertions, 43 deletions
diff --git a/content/docs/architecture_guide/performance.md b/content/docs/architecture_guide/performance.md deleted file mode 100644 index f2e928b84..000000000 --- a/content/docs/architecture_guide/performance.md +++ /dev/null @@ -1,39 +0,0 @@ -+++ -title = "Performance" -weight = 30 -+++ -gVisor is designed to provide a secure, virtualized environment while preserving -key benefits of containerization such as small fixed overheads and a dynamic -resource footprint. For containerized infrastructure, this can provide an “easy -button” for sandboxing untrusted workloads: there are no changes to the -fundamental resource model. - -However, there are clear trade-offs in this approach. gVisor does not fully -implement the system call surface provided by an upstream Linux kernel. We are -always working to improve this support, and current limitations are described -[Compatibility](../../user_guide/compatibility). - -gVisor also imposes runtime costs over native containers. These costs come in -two forms: additional cycles and memory usage, and they come from two different -sources. First, the existence of the Sentry itself means that additional memory -will be required, and application system calls generally traverse additional -layers. We place an emphasis on [Security](../security/) and therefore chose to -use a language for the Sentry that provides lots of benefits in this domain, but -may not offer the raw performance of other choices. Costs imposed by this design -are structural costs. - -Second, as gVisor is a fresh implementation of the system call surface, many of -the subsystems or specific calls are not as optimized as more mature -implementations. A good example here is the network stack, which is continuing -to evolve but does not support all the advanced recovery mechanisms offered by -other stacks and is less CPU efficient. This an implementation cost and should -not be confused with structural costs. Improvements here are ongoing and largely -driven by the workloads that matter to gVisor contributors and users. - -## Structural Costs - -The structural costs of gVisor are heavily influenced by the platform choice, -which implements system call interception. Today, gVisor supports a variety of -platforms. These platforms present distinct performance, compatibility and -security trade-offs. For example, the KVM platform low overhead system call -interception but runs poorly with nested virtualization. diff --git a/content/docs/user_guide/FAQ.md b/content/docs/user_guide/FAQ.md index 86ac70fa8..167933f9f 100644 --- a/content/docs/user_guide/FAQ.md +++ b/content/docs/user_guide/FAQ.md @@ -30,7 +30,3 @@ There are also different filesystem modes that can be used to avoid this issue. ### What's the security model? See the [Security Model](../../architecture_guide/security/). - -### What's the expected performance? - -See the [Performance Guide](../../architecture_guide/performance/). |