flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From greghogan <...@git.apache.org>
Subject [GitHub] flink pull request #5277: [hotfix][docs]Review to reduce passive voice, impr...
Date Wed, 10 Jan 2018 20:56:50 GMT
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?


---

Mime
View raw message