[ https://issues.apache.org/jira/browse/YARN-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673703#comment-13673703 ]
Arun C Murthy commented on YARN-689: ------------------------------------ bq. Unless I'm missing something, if today you set the minimum to 128M, you run into the issue you describe "then trying to get reservations to work for 1.7G v/s 1.9G on can be very hard. Worse, this leads to lots of nodes with <1G fragments leading to poor utilization.". No? Again, if minimum == increment, this does not arise at all. bq. It seems that there's a concern about impacting CS with this change It's more than just that - I thought I made this clear. I don't see this as the right thing to do directionally/architecturally for YARN - this change doesn't smell right to me. This is why I'm against this change in the protocol. I won't block changes to FS as long as they don't expose this on the protocol. Thanks. > Add multiplier unit to resourcecapabilities > ------------------------------------------- > > Key: YARN-689 > URL: https://issues.apache.org/jira/browse/YARN-689 > Project: Hadoop YARN > Issue Type: Bug > Components: api, scheduler > Affects Versions: 2.0.4-alpha > Reporter: Alejandro Abdelnur > Assignee: Alejandro Abdelnur > Attachments: YARN-689.patch, YARN-689.patch, YARN-689.patch, > YARN-689.patch, YARN-689.patch > > > Currently we overloading the minimum resource value as the actual multiplier > used by the scheduler. > Today with a minimum memory set to 1GB, requests for 1.5GB are always > translated to allocation of 2GB. > We should decouple the minimum allocation from the multiplier. > The multiplier should also be exposed to the client via the > RegisterApplicationMasterResponse -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira