> On Jan. 6, 2016, 10:09 a.m., Adam B wrote:
> > src/master/allocator/mesos/hierarchical.cpp, lines 1048-1051
> > <https://reviews.apache.org/r/41597/diff/36/?file=1183523#file1183523line1048>
> >
> >     Does anything rely on this behavior of erasing 1.0s from the hashmap? I 
> > know it'll (slightly) reduce the number of bits in memory and persisted in 
> > the registry, but is there any other reason to do this? Might be a 
> > premature optimization. Besides, the sorters still get updated for 1.0s.
> >     Thoughts?

There is no any other reasons for erasing the default weight frm the hasmap. In 
HierarchicalAllocatorProcess::roleWeight method of allocator, if the role's 
weight does not exist in weights hashmap, then it will return 1.0. so it is 
make sence to the erase it.

In addition, we should keep the same behaviour to only save the non-default 
weights in allocator, master and registry.


- Yongqiao


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41597/#review113035
-----------------------------------------------------------


On Jan. 6, 2016, 2:14 a.m., Yongqiao Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41597/
> -----------------------------------------------------------
> 
> (Updated Jan. 6, 2016, 2:14 a.m.)
> 
> 
> Review request for mesos, Adam B, Neil Conway, and Qian Zhang.
> 
> 
> Bugs: MESOS-3943
>     https://issues.apache.org/jira/browse/MESOS-3943
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Add the interface in allocator to support updating weight
> at runtime, and the allocator is invoked to allocate the
> resources based on the updated weights later.
> 
> 
> Diffs
> -----
> 
>   include/mesos/master/allocator.hpp f7ada68d7111486d264284990996413bb33333d6 
>   include/mesos/mesos.proto 158e08774c4a4fa5ec667388c61e55dbdafc7f67 
>   include/mesos/v1/mesos.proto c6c5a81eb9282d188d90fe395e1c16633a2a64cf 
>   src/master/allocator/mesos/allocator.hpp 
> 50ef3b20f34bc6d87cbeccabcebec9a5031a6554 
>   src/master/allocator/mesos/hierarchical.hpp 
> 86ea5a402ed67f8f22f11d5730147cd907d66a08 
>   src/master/allocator/mesos/hierarchical.cpp 
> df8bccaf2b8cfc0cb5ca18d4867371ae7a84c12f 
>   src/master/allocator/sorter/drf/sorter.hpp 
> 050896e8b12cd4097ccd137d5284d6b39b0f06ab 
>   src/master/allocator/sorter/drf/sorter.cpp 
> 3a442f121f3a1505513877a5c78458a4b8d0a824 
>   src/master/allocator/sorter/sorter.hpp 
> 7be6b44a762fd62c2cd7f28b4dc4865a4587ed26 
>   src/tests/allocator.hpp 9bdfaecf1a148f113ad52956b50ed7cabe0902ef 
> 
> Diff: https://reviews.apache.org/r/41597/diff/
> 
> 
> Testing
> -------
> 
> Make & Make check successfully!
> 
> Test case: https://reviews.apache.org/r/41672/
> 
> 
> Thanks,
> 
> Yongqiao Wang
> 
>

Reply via email to