diff options
Diffstat (limited to 'g3doc')
| -rw-r--r-- | g3doc/architecture_guide/performance.md | 4 | ||||
| -rw-r--r-- | g3doc/architecture_guide/resources.md | 4 | ||||
| -rw-r--r-- | g3doc/user_guide/networking.md | 7 |
3 files changed, 7 insertions, 8 deletions
diff --git a/g3doc/architecture_guide/performance.md b/g3doc/architecture_guide/performance.md index 39dbb0045..b981f0c01 100644 --- a/g3doc/architecture_guide/performance.md +++ b/g3doc/architecture_guide/performance.md @@ -30,7 +30,7 @@ is distinct from **structural costs**. Improvements here are ongoing and driven by the workloads that matter to gVisor users and contributors. This page provides a guide for understanding baseline performance, and calls out -distint **structural costs** and **implementation costs**, highlighting where +distinct **structural costs** and **implementation costs**, highlighting where improvements are possible and not possible. While we include a variety of workloads here, it’s worth emphasizing that gVisor @@ -211,7 +211,7 @@ url="/performance/applications.csv" title="perf.py http.(node|ruby) The above figure shows the result of simple `node` and `ruby` web services that render a template upon receiving a request. Because these synthetic benchmarks -do minimal work per request, must like the `redis` case, they suffer from high +do minimal work per request, much like the `redis` case, they suffer from high overheads. In practice, the more work an application does the smaller the impact of **structural costs** become. diff --git a/g3doc/architecture_guide/resources.md b/g3doc/architecture_guide/resources.md index 1dec37bd1..fc997d40c 100644 --- a/g3doc/architecture_guide/resources.md +++ b/g3doc/architecture_guide/resources.md @@ -19,12 +19,12 @@ sandboxed process: Much like a Virtual Machine (VM), a gVisor sandbox appears as an opaque process on the system. Processes within the sandbox do not manifest as processes on the -host system, and process-level interactions within the sandbox requires entering +host system, and process-level interactions within the sandbox require entering the sandbox (e.g. via a [Docker exec][exec]). ## Networking -The sandbox attaches a network endpoint to the system, but runs it's own network +The sandbox attaches a network endpoint to the system, but runs its own network stack. All network resources, other than packets in flight on the host, exist only inside the sandbox, bound by relevant resource limits. diff --git a/g3doc/user_guide/networking.md b/g3doc/user_guide/networking.md index 4aa394c91..95f675633 100644 --- a/g3doc/user_guide/networking.md +++ b/g3doc/user_guide/networking.md @@ -2,9 +2,9 @@ [TOC] -gVisor implements its own network stack called [netstack][netstack]. All aspects -of the network stack are handled inside the Sentry — including TCP connection -state, control messages, and packet assembly — keeping it isolated from the host +gVisor implements its own network stack called netstack. All aspects of the +network stack are handled inside the Sentry — including TCP connection state, +control messages, and packet assembly — keeping it isolated from the host network stack. Data link layer packets are written directly to the virtual device inside the network namespace setup by Docker or Kubernetes. @@ -82,4 +82,3 @@ Offload (GSO) to run with a kernel that is newer than 3.17. Add the } ``` -[netstack]: https://github.com/google/netstack |