diff options
Diffstat (limited to 'g3doc/architecture_guide')
| -rw-r--r-- | g3doc/architecture_guide/performance.md | 4 | ||||
| -rw-r--r-- | g3doc/architecture_guide/resources.md | 4 | ||||
| -rw-r--r-- | g3doc/architecture_guide/security.md | 2 |
3 files changed, 5 insertions, 5 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/architecture_guide/security.md b/g3doc/architecture_guide/security.md index b99b86332..9363d834c 100644 --- a/g3doc/architecture_guide/security.md +++ b/g3doc/architecture_guide/security.md @@ -104,7 +104,7 @@ interactions with a guest operating system and a set of virtualized hardware devices. These hardware devices are then implemented via the host System API by a Virtual Machine Monitor (VMM). The Sentry similarly prevents direct interactions by providing its own implementation of the System API that the -application must interact with. Applications are not able to to directly craft +application must interact with. Applications are not able to directly craft specific arguments or flags for the host System API, or interact directly with host primitives. |