mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Review Request 41658: Track the allocation candidates to bound the allocation queue.
Date Tue, 21 Jun 2016 15:39:56 GMT


> On June 21, 2016, 3:25 p.m., Jiang Yan Xu wrote:
> > src/master/allocator/mesos/hierarchical.hpp, line 368
> > <https://reviews.apache.org/r/41658/diff/1/?file=1174679#file1174679line368>
> >
> >     Instead of using a counter I think the following is equivalent but simpler:
> >     
> >     ```
> >     bool allocationPending;
> >     ```
> >     
> >     So instead of always dispatching into the queue which results in many noops,
we don't dispatch if we know there is already an allocation pending in the queue. We merely
update `allocationCandidates`.
> >     
> >     Later after the allocation is run we reset the bool.
> >     
> >     Make sense?

That's not the same thing. The allocation counter lets you take the the *last* allocation
in the queue, rather than any. For example, imagine the dispatch queue contains TTTTATTT (T
is some event, A is an allocation). The allocation counter turns this into TTTTATTTA but only
the last A would be executed. So if T adds allocation candidates you would end up doing fewer
allocations.

Note that I'm not claiming that this makes a difference in practice; it could well be that
the boolean flag is good enough for the common cases you are trying to address. Just giving
the background for the counter.


> On June 21, 2016, 3:25 p.m., Jiang Yan Xu wrote:
> > src/master/allocator/mesos/hierarchical.cpp, line 1080
> > <https://reviews.apache.org/r/41658/diff/1/?file=1174680#file1174680line1080>
> >
> >     This uses `true` but I don't see why batch needs to be different.

The force is to ensure that allocations are not starved out. If there is a lot of churn and
we keep delaying the actial allocation, you can imagine a scenario where the allocation is
deferred indefinitely. This ensures that allocations occur at least at the batch interval.


> On June 21, 2016, 3:25 p.m., Jiang Yan Xu wrote:
> > src/master/allocator/mesos/hierarchical.cpp, line 1137
> > <https://reviews.apache.org/r/41658/diff/1/?file=1174680#file1174680line1137>
> >
> >     No need to rename the method?

It made it clearer since there are a number of overloads of ``allocate()``.


- James


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


On Dec. 22, 2015, 7:56 p.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41658/
> -----------------------------------------------------------
> 
> (Updated Dec. 22, 2015, 7:56 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Klaus Ma.
> 
> 
> Bugs: MESOS-3157
>     https://issues.apache.org/jira/browse/MESOS-3157
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> When there is churn in the cluster, frequent resource allocation
> is required.  Maintain a set of allocation candidates so that we
> don't end up running the same allocation multiple times.
> 
> This review is just for feedback. Not proposing it to be berged at this time.
> 
> 
> Diffs
> -----
> 
>   src/master/allocator/mesos/hierarchical.hpp 86ea5a402ed67f8f22f11d5730147cd907d66a08

>   src/master/allocator/mesos/hierarchical.cpp 775182515dcb52bd873ecdf98c827320251a59c8

> 
> Diff: https://reviews.apache.org/r/41658/diff/
> 
> 
> Testing
> -------
> 
> make check.
> 
> 
> Thanks,
> 
> James Peach
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message