> On May 16, 2015, 1: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?
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? - Ian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/34310/#review84039 ----------------------------------------------------------- On May 18, 2015, 10:33 a.m., Ian Downes wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/34310/ > ----------------------------------------------------------- > > (Updated May 18, 2015, 10:33 a.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 > 6a5b2b5c6e2844fe1a10815956569194b6f56681 > > Diff: https://reviews.apache.org/r/34310/diff/ > > > Testing > ------- > > > Thanks, > > Ian Downes > >
