> On Sept. 25, 2015, 9:55 p.m., Joris Van Remoortere wrote:
> > src/tests/hierarchical_allocator_tests.cpp, line 1397
> > <https://reviews.apache.org/r/38649/diff/1/?file=1081568#file1081568line1397>
> >
> >     This causes a race that can corrupt the allocator:
> >     - The calls to `allocator->recoverResources` are asynchronously invoked 
> > inside the actor (on a separate thread)
> >     - This call to `hproc->allocate` is synchronous and runs in the 
> > execution context of the current thread
> >     - The Allocator is an Actor, and all our actors are written to be 
> > driven by libprocess (i.e. only 1 thread invoking a function at any given 
> > point in time, only 1 execution context)
> >     The way this code is currently set up the `recoverResources` functions 
> > may be executed simultaneously as the `allocate` function.
> >     
> >     Let me know if this is not clear.
> >     
> >     You want to do something along these lines:
> >     ```
> >     Future<Nothing> result = dispatch(hproc->self(), 
> > &HierarchicalDRFAllocatorProcess::allocate);
> >     
> >     result.await();
> >     ```
> >     
> >     However; the allocate function would need to return something other 
> > than `void` such as `Nothing` for that to work.
> 
> James Peach wrote:
>     Yeh, the place where I call ```allocate()``` directly is a total hack. To 
> do it right, I'd have to plumb an ```allocate()``` call all the way through 
> the ```Allocator``` interface. Is that the right approach?

I updated the test to force the allocation using ```Clock``` manipulation 
rather than explicitly calling the allocator interface. It still seems to work 
OK.


- James


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


On Sept. 30, 2015, 10 p.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/38649/
> -----------------------------------------------------------
> 
> (Updated Sept. 30, 2015, 10 p.m.)
> 
> 
> Review request for mesos and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-3493
>     https://issues.apache.org/jira/browse/MESOS-3493
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This benchmark starts a number of slaves and frameworks, then cycles
> the allocator. On each allocation pass, the frameworks decline all
> the offers. This leads to increasing numbers of refusal filters in
> the allocator, and the allocation slows down. After around 200
> cycles the slowdown increases out of proportion.
> 
> 
> Diffs
> -----
> 
>   src/tests/hierarchical_allocator_tests.cpp 
> 505b9de3d8d888c296f6103c80fe9f0ef1c2ca16 
> 
> Diff: https://reviews.apache.org/r/38649/diff/
> 
> 
> Testing
> -------
> 
> make check && make bench
> 
> 
> Thanks,
> 
> James Peach
> 
>

Reply via email to