> On June 27, 2014, 9:21 p.m., Vinod Kone wrote:
> > src/linux/cgroups.cpp, lines 453-463
> > <https://reviews.apache.org/r/22981/diff/1/?file=617552#file617552line453>
> >
> >     I don't think this is going to work.
> >     
> >     First off, the cpushare isolator needs to be made aware of the 
> > co-mounted hierarchy. Otherwise lot of its methods are either going to fail 
> > or do something wrong (recover(), cleanup(), usage()).
> >     
> >     Second, this is being done transparently to the isolator by adding a 
> > special case to the underlying cgroups library. I think this is breaking 
> > the abstraction. It should be done the other way.
> >     
> >     Here is what I suggest:
> >     
> >     In cpushare isolator prepare() figure out if we there is already a 
> > co-mounted cpu,cpuacct hierarchy. If yes "hierarchies" map should just 
> > contain one key "cpu,cpuacct". If not it should do what it is doing today.
> >     
> >     You would also want to update recover() and update() to make sure they 
> > are not using hard-coded keys into the map (currently I see that they are 
> > using hardcoded "cpu" and "cpuacct" keys.)  cleanup() seems to be fine.
> 
> Timothy St. Clair wrote:
>     'First off, the cpushare isolator needs to be made aware of the 
> co-mounted hierarchy. Otherwise lot of its methods are either going to fail 
> or do something wrong (recover(), cleanup(), usage()).'  
>     
>     Why? How? I fail to see how this changes any behavior, could you please 
> elaborate... 
>     
>     'Second, this is being done transparently to the isolator by adding a 
> special case to the underlying cgroups library. I think this is breaking the 
> abstraction. It should be done the other way.'
>     
>     Maybe I'm missing something, why does/should the isolator care?  It's 
> done below its radar.   
>     
>     $ pwd && ls -la 
>     /sys/fs/cgroup
>     total 0
>     drwxr-xr-x. 12 root root 280 Jul  7 13:26 .
>     drwxr-xr-x.  7 root root   0 Jul  8 12:04 ..
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 blkio
>     lrwxrwxrwx.  1 root root  11 Jul  7 13:26 cpu -> cpu,cpuacct
>     lrwxrwxrwx.  1 root root  11 Jul  7 13:26 cpuacct -> cpu,cpuacct
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 cpu,cpuacct
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 cpuset
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 devices
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 freezer
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 hugetlb
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 memory
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 net_cls
>     drwxr-xr-x.  2 root root   0 Jul  7 13:26 perf_event
>     drwxr-xr-x.  4 root root   0 Jul  7 13:26 systemd
>     
>
> 
> Vinod Kone wrote:
>     I didn't realize systemd creates symbolic links for "cpu" and "cpuacct" 
> hierarchies to "cpu,cpuacct". Thats interesting.
>     
>     The way recover() is written for the cpu isolator, the current code might 
> work. But I don't think it would work for cleanup() because it will try to 
> destroy the same cgroup twice? Did you test your patch with and without 
> co-mounted hierarchies?
>     
>     Also, I still think making cgroups::prepare() have an exception for 
> co-mounted hierarchies (that too only cpu and cpuacct) is weird. I would 
> rather have this intelligence in a layer above, cpu isolator. Have you 
> considered that? Does that make it complicated?
>     
>

I tested only platforms with sytemd, b/c all my platforms that I run use 
systemd now.

I'll take a look @ cleanup() and verify.  

I'm still not following the logic behind the co-mounting exception at the 
isolator layer, I think there is some implied context that I'm missing.  Why do 
you think that it makes more sense to put it there?   


- Timothy


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


On June 25, 2014, 8:01 p.m., Timothy St. Clair wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22981/
> -----------------------------------------------------------
> 
> (Updated June 25, 2014, 8:01 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Vinod Kone.
> 
> 
> Bugs: MESOS-1195
>     https://issues.apache.org/jira/browse/MESOS-1195
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Enable co-mounting of only the cpu & cpuacct.  Systemd will co-mount by 
> default.
> 
> 
> Diffs
> -----
> 
>   src/linux/cgroups.cpp 5472eb8 
> 
> Diff: https://reviews.apache.org/r/22981/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> + full run of marathon jobs.
> 
> 
> Thanks,
> 
> Timothy St. Clair
> 
>

Reply via email to