Github user greghogan commented on a diff in the pull request:
https://github.com/apache/flink/pull/5277#discussion_r160795540
--- 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.
--- End diff --
Preserve the line split? I'm not sure what the second sentence is saying.
Typically hyper-threads are reported as separate cores so would not each slot
take a single hardware thread context?
---