> On May 16, 2015, 8:03 p.m., Joris Van Remoortere wrote:
> > Hi Ian,
> > 
> > I'm wondering about the `Note` regarding only setting the scheduling policy 
> > to IDLE if the initial resources are revocable. I think this exposes many 
> > scenarios where the isolator will seem `enabled` to the operator, but won't 
> > actually be isolating correctly.
> > I don't think it is uncommon to launch an executor with non-revocable 
> > resources, and then later launch BE tasks with revocable resources. This 
> > pattern would always lead to the isolator being in-effective right?
> > 
> > I am not super familiar with the rules around the isolators, but why can we 
> > not adjust the policy within the update() call as opposed to in the 
> > isolate() function?
> 
> Ian Downes wrote:
>     This is not a limitation of the isolator interface but a complexity of 
> setting the scheduling policy because it's task rather than cgroup based. 
> We'd need to ensure we set it on all tasks and forking children. One approach 
> could be to briefly freeze the cgroup and set the scheduling policy but I'm 
> concerned that if the slave dies during the freeze/set/unfreeze operation 
> then we've frozen a running container. Otherwise, we need some hackery as 
> used in os:killtree() to ensure we get every task.
>     
>     We need to do it in isolate() regardless because that's the initial 
> forked child which will later exec the executor and we may never get a 
> subsequent update(). I'll look at adding it also to the update() call to 
> capture updates to the resources after the executor has launched.
>     
>     I presume we also want to support the reverse update from having some 
> revocable to having no revocable CPU, i.e., SCHED_IDLE -> SCHED_OTHER?

Why does it need to be as complicated as os::killtree? If we rely on cgroups to 
provide the list of processes, we shouldn't have to do the stopping and tree 
traversal logic. Just have to iterate on cgroup::processes until everything is 
set, no? Are you worried about the fork-bomb case where we iterate forever, 
unless the freezer is eventually used?


- Ben


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


On May 29, 2015, 7:57 p.m., Ian Downes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/34310/
> -----------------------------------------------------------
> 
> (Updated May 29, 2015, 7:57 p.m.)
> 
> 
> Review request for mesos, Joris Van Remoortere, Niklas Nielsen, and Vinod 
> Kone.
> 
> 
> Bugs: MESOS-2652
>     https://issues.apache.org/jira/browse/MESOS-2652
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Use IDLE scheduling for revocable CPU in cgroups isolator.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/isolators/cgroups/cpushare.hpp 
> ff4a9dbdb1b655e71bf87dcee8fe62433d396f52 
>   src/slave/containerizer/isolators/cgroups/cpushare.cpp 
> e3b5e2aa8ba06eec82b929144627d044f6b19d9d 
>   src/slave/flags.hpp 944ed794b6dc8a2d3712145a15b6b27cebf26a22 
>   src/slave/flags.cpp 6b7c61ea1a9f3b5d401d2aec935188a1b70c1738 
>   src/tests/isolator_tests.cpp 24c71b7906a92bdc84a38e88d6084ab09e3cf2ab 
> 
> Diff: https://reviews.apache.org/r/34310/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Ian Downes
> 
>

Reply via email to