Re: Review Request 34310: Use IDLE scheduling for revocable CPU in cgroups isolator.

[Ben Mahler <be...@gmail.com>]

> 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
> 
>