Github user greghogan commented on a diff in the pull request:
https://github.com/apache/flink/pull/5277#discussion_r160795814
--- Diff: docs/concepts/runtime.md ---
@@ -88,40 +94,36 @@ By default, Flink allows subtasks to share slots even
if they are subtasks of di
they are from the same job. The result is that one slot may hold an entire
pipeline of the
job. Allowing this *slot sharing* has two main benefits:
- - A Flink cluster needs exactly as many task slots as the highest
parallelism used in the job.
- No need to calculate how many tasks (with varying parallelism) a
program contains in total.
+ - A Flink cluster needs as many task slots as the highest parallelism
used in the job.
+ There's no need to calculate how many tasks (with varying parallelism)
a program contains in total.
- It is easier to get better resource utilization. Without slot sharing,
the non-intensive
- *source/map()* subtasks would block as many resources as the resource
intensive *window* subtasks.
+ *source/map()* subtasks would block as many resources as the
resource-intensive *window* subtasks.
With slot sharing, increasing the base parallelism in our example from
two to six yields full utilization of the
- slotted resources, while making sure that the heavy subtasks are
fairly distributed among the TaskManagers.
+ slotted resources, while making sure that the heavy subtasks are
evenly distributed among the TaskManagers.
<img src="../fig/slot_sharing.svg" alt="TaskManagers with shared Task
Slots" class="offset" width="80%" />
-The APIs also include a *[resource
group](../dev/datastream_api.html#task-chaining-and-resource-groups)* mechanism
which can be used to prevent undesirable slot sharing.
+The APIs also include a *[resource
group](../dev/datastream_api.html#task-chaining-and-resource-groups)* mechanism
which you can use to prevent undesirable slot sharing.
-As a rule-of-thumb, a good default number of task slots would be the
number of CPU cores.
-With hyper-threading, each slot then takes 2 or more hardware thread
contexts.
+As a rule-of-thumb, a reasonable default number of task slots would be the
number of CPU cores. With hyper-threading, each slot then takes 2 or more
hardware thread contexts.
{% top %}
## State Backends
-The exact data structures in which the key/values indexes are stored
depends on the chosen [state backend](../ops/state/state_backends.html). One
state backend
-stores data in an in-memory hash map, another state backend uses
[RocksDB](http://rocksdb.org) as the key/value store.
-In addition to defining the data structure that holds the state, the state
backends also implement the logic to
-take a point-in-time snapshot of the key/value state and store that
snapshot as part of a checkpoint.
+The exact data structures which store the key/values indexes depends on
the chosen [state backend](../ops/state/state_backends.html). One state backend
stores data in an in-memory hash map, another state backend uses
[RocksDB](http://rocksdb.org) as the key/value store. In addition to defining
the data structure that holds the state, the state backends also implement the
logic to take a point-in-time snapshot of the key/value state and store that
snapshot as part of a checkpoint.
--- End diff --
Preserve the line splits? The conversion to HTML ignores single newlines.
---
