Details

    • Type: Sub-task
    • Status: Patch Available
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: YARN-3926
    • Fix Version/s: None
    • Component/s: resourcemanager
    • Labels:
      None

      Description

      The dominant param assumes there are only two resources, i.e. true means to compare the dominant, and false means to compare the subordinate. Now that there are n resources, this parameter no longer makes sense.

      1. YARN-6610.001.patch
        6 kB
        Daniel Templeton

        Activity

        Hide
        templedf Daniel Templeton added a comment -

        Here's a first pass at making the compare make sense again. Thoughts? The patch still needs tests.

        Show
        templedf Daniel Templeton added a comment - Here's a first pass at making the compare make sense again. Thoughts? The patch still needs tests.
        Hide
        hadoopqa Hadoop QA added a comment -
        -1 overall



        Vote Subsystem Runtime Comment
        0 reexec 0m 0s Docker mode activated.
        -1 patch 0m 7s YARN-6610 does not apply to trunk. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help.



        Subsystem Report/Notes
        JIRA Issue YARN-6610
        JIRA Patch URL https://issues.apache.org/jira/secure/attachment/12868398/YARN-6610.001.patch
        Console output https://builds.apache.org/job/PreCommit-YARN-Build/15942/console
        Powered by Apache Yetus 0.5.0-SNAPSHOT http://yetus.apache.org

        This message was automatically generated.

        Show
        hadoopqa Hadoop QA added a comment - -1 overall Vote Subsystem Runtime Comment 0 reexec 0m 0s Docker mode activated. -1 patch 0m 7s YARN-6610 does not apply to trunk. Rebase required? Wrong Branch? See https://wiki.apache.org/hadoop/HowToContribute for help. Subsystem Report/Notes JIRA Issue YARN-6610 JIRA Patch URL https://issues.apache.org/jira/secure/attachment/12868398/YARN-6610.001.patch Console output https://builds.apache.org/job/PreCommit-YARN-Build/15942/console Powered by Apache Yetus 0.5.0-SNAPSHOT http://yetus.apache.org This message was automatically generated.
        Hide
        sunilg Sunil G added a comment -

        Converted as a sub-task under YANR-3926, Please revert if any issues.

        Show
        sunilg Sunil G added a comment - Converted as a sub-task under YANR-3926, Please revert if any issues.
        Hide
        sunilg Sunil G added a comment -

        Daniel Templeton, thanks for the patch.

        I have some more thoughts to add here. Earlier, we were considering only Memory and VCores for dominance comparison. Given dominant parameter, we were trying to see which resource has a larger share and return the comparison value as per that.

        In resource profile case, where more resource are considered, i do not think all resources has to be considered for larger share comparison. There could be "scarce" resources such as GPU. In a case where there are very less GPU machines in cluster, at some point of time, GPU can also become higher to VCores or Memory. But I do not think, such a scenario could be handled only by resource calculator easily. Constraints, and rich placement strategy set will also play a part to consume "scarce" resources.

        In general, "scarce" object could be labelled/pre-configured but also could be identified by YARN. cc/Varun Vasudev and Wangda Tan

        Show
        sunilg Sunil G added a comment - Daniel Templeton , thanks for the patch. I have some more thoughts to add here. Earlier, we were considering only Memory and VCores for dominance comparison. Given dominant parameter, we were trying to see which resource has a larger share and return the comparison value as per that. In resource profile case, where more resource are considered, i do not think all resources has to be considered for larger share comparison. There could be "scarce" resources such as GPU. In a case where there are very less GPU machines in cluster, at some point of time, GPU can also become higher to VCores or Memory. But I do not think, such a scenario could be handled only by resource calculator easily. Constraints, and rich placement strategy set will also play a part to consume "scarce" resources. In general, "scarce" object could be labelled/pre-configured but also could be identified by YARN. cc/ Varun Vasudev and Wangda Tan
        Hide
        templedf Daniel Templeton added a comment -

        I had similar thoughts. Maybe instead of adding scarce resources, we could cover most use cases by doing what I did in this patch plus adding a calculator that looks at only CPU and memory, like the pre-resource-types DominantResourceCalculator. (I guess the other way to look at it would be to have DominantResourceCalculator ignore everything except CPU and memory and add a new calculator to do what I did in the patch.)

        Show
        templedf Daniel Templeton added a comment - I had similar thoughts. Maybe instead of adding scarce resources, we could cover most use cases by doing what I did in this patch plus adding a calculator that looks at only CPU and memory, like the pre-resource-types DominantResourceCalculator . (I guess the other way to look at it would be to have DominantResourceCalculator ignore everything except CPU and memory and add a new calculator to do what I did in the patch.)
        Hide
        sunilg Sunil G added a comment -

        Thanks Daniel Templeton
        I think the approach taken in this patch in general sounds fine. However we iterate over resourceNames, which is full list of resources. I guess we can define Memory and CPU as resources to calculate for. I am not so sure whether its too early to expose as a config for user to express.

        Show
        sunilg Sunil G added a comment - Thanks Daniel Templeton I think the approach taken in this patch in general sounds fine. However we iterate over resourceNames , which is full list of resources. I guess we can define Memory and CPU as resources to calculate for. I am not so sure whether its too early to expose as a config for user to express.
        Hide
        templedf Daniel Templeton added a comment -

        After a long discussion with Karthik Kambatla, I think I'm now convinced that there's no correctness issue with using DRF in a multi-resource configuration. There is, of course, the performance issue created by increasing the number of dimensions in the resource comparisons, but that's an issue to be resolved for resource types in general. I think the posted patch should be fine.

        Show
        templedf Daniel Templeton added a comment - After a long discussion with Karthik Kambatla , I think I'm now convinced that there's no correctness issue with using DRF in a multi-resource configuration. There is, of course, the performance issue created by increasing the number of dimensions in the resource comparisons, but that's an issue to be resolved for resource types in general. I think the posted patch should be fine.
        Hide
        yufeigu Yufei Gu added a comment - - edited

        Hi Daniel Templeton, the patch doesn't apply to trunk. Can you rebase it? Seems like it can apply for branch YARN-3926. Just need to change the patch file name.

        Show
        yufeigu Yufei Gu added a comment - - edited Hi Daniel Templeton , the patch doesn't apply to trunk. Can you rebase it? Seems like it can apply for branch YARN-3926 . Just need to change the patch file name.
        Hide
        templedf Daniel Templeton added a comment -

        Sunil G, I don't think we can ignore everything except CPU and memory. Consider that scarce resources are typically going to be expensive. We want to make sure they have priority when scheduling, so we want them to be treated according to their dominant resource, not just CPU and memory.

        Show
        templedf Daniel Templeton added a comment - Sunil G , I don't think we can ignore everything except CPU and memory. Consider that scarce resources are typically going to be expensive. We want to make sure they have priority when scheduling, so we want them to be treated according to their dominant resource, not just CPU and memory.

          People

          • Assignee:
            templedf Daniel Templeton
            Reporter:
            templedf Daniel Templeton
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:

              Development