MESOS-4694

2016-07-06 Thread Dario Rexin
Hi all, I would like to revive https://issues.apache.org/jira/browse/MESOS-4694 <https://issues.apache.org/jira/browse/MESOS-4694>, especially https://reviews.apache.org/r/43666/ <https://reviews.apache.org/r/43666/>. We heavily depend on this patch and would love to see it merged.

Re: MESOS-4694

2016-07-06 Thread Benjamin Mahler
te more quickly when there are many frameworks that are in the suppressed state, because we have to loop over fewer clients. Is this an accurate interpretation? On Wed, Jul 6, 2016 at 2:08 PM, Dario Rexin wrote: > Hi all, > > I would like to revive https://issues.apache.org/jira/browse/M

Re: MESOS-4694

2016-07-06 Thread Dario Rexin
s that are in the suppressed state, because we have to loop over > fewer clients. Is this an accurate interpretation? > > On Wed, Jul 6, 2016 at 2:08 PM, Dario Rexin wrote: > >> Hi all, >> >> I would like to revive https://issues.apache.org/jira/browse/MESOS-4694 &l

Re: MESOS-4694

2016-07-07 Thread Guangya Liu
is that this change > makes the allocation loop complete more quickly when there are many > frameworks that are in the suppressed state, because we have to loop over > fewer clients. Is this an accurate interpretation? > > On Wed, Jul 6, 2016 at 2:08 PM, Dario Rexin wrote: > > Hi

Re: MESOS-4694

2016-07-07 Thread Joris Van Remoortere
hard to interpret these numbers without reading > the > > benchmark code. My interpretation of these numbers is that this change > > makes the allocation loop complete more quickly when there are many > > frameworks that are in the suppressed state, because we have to loop over >

Re: MESOS-4694

2016-07-07 Thread Dario Rexin
osted seems to only take this half-way: >> suppress >>> = deactivation in the allocator, but not in the master. >>> >>> Also, Dario it's a bit hard to interpret these numbers without reading >> the >>> benchmark code. My interpretation of these number

Re: MESOS-4694

2016-07-07 Thread Dario Rexin
>>>> On Jul 6, 2016, at 2:56 PM, Benjamin Mahler wrote: >>>> >>>> +implementer and shepherd of SUPPRESS >>>> >>>> Is there any reason we didn't already just "deactivate" frameworks that >>>> were suppressing

Re: MESOS-4694

2016-07-07 Thread Joris Van Remoortere
nks, > >>>> -- > >>>>  Dario > >>>> > >>>> On Jul 6, 2016, at 2:56 PM, Benjamin Mahler > wrote: > >>>> > >>>> +implementer and shepherd of SUPPRESS > >>>> > >>>> Is there any reason we did

Re: MESOS-4694

2016-07-07 Thread Dario Rexin
;>> Thanks, > >>>> -- > >>>>  Dario > >>>> > >>>> On Jul 6, 2016, at 2:56 PM, Benjamin Mahler >>>> <mailto:bmah...@apache.org>> wrote: > >>>> > >>>> +implementer and shepherd of SU

Re: MESOS-4694

2016-07-08 Thread Alex Rukletsov
t;>>> Thanks, > >>>> -- > >>>>  Dario > >>>> > >>>> On Jul 6, 2016, at 2:56 PM, Benjamin Mahler > wrote: > >>>> > >>>> +implementer and shepherd of SUPPRESS > >>>>

Re: MESOS-4694

2016-07-08 Thread Dario Rexin
vating the framework in the master >> would >>>>>> have. The framework is still active and listening for events / sending >>>>>> calls. Could you please elaborate? >>>>>> >>>>>> Thanks, >>>>>> -- >>&

Re: MESOS-4694

2016-07-18 Thread Alex Rukletsov
inod, > >>>>>> > >>>>>> thanks for your reply. The reason it’s so much faster is because the > >>>>>> sorting is a lot faster with fewer frameworks. Looping shouldn’t > make > >> a > >>>>>> huge differen

Re: MESOS-4694

2016-07-18 Thread Dario Rexin
s://issues.apache.org/jira/browse/MESOS-5800 to trace. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Guangya >>>>>>> >>>>>>> >>>>>>> >>>>>>