> On Nov. 19, 2012, 12:21 a.m., Ben Mahler wrote:
> > src/slave/cgroups_isolation_module.cpp, line 593
> > <https://reviews.apache.org/r/8108/diff/1/?file=191733#file191733line593>
> >
> >     Looks like setting cpuset.mems is also mandatory here..
> >     
> > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-cpuset.html
> 
> Jie Yu wrote:
>     And seems that cpuset.mems is different from cpuset.cpus.
>     
>     For example, it's possible that
>     cpuset.mems = 0-1
>     cpuset.cpus = 0-15
>     
>     Probably it means that there are two chips, each chip has a memory node 
> associated with, and each chip has 8 hardware thread (probably 4-cores with 
> hyper threading).
> 
> Jie Yu wrote:
>     No sure whether you need to configure cpuset.mems at all if you don't 
> care about memory affinity. Probably you can just set cpuset.mems to be the 
> value of all the available memory nodes.

Agreed, for this first pass, I think we shouldn't consider memory affinity.

We do need to be careful in that we must use a (possibly equal) subset of the 
hierarchy's cpuset.cpus and cpuset.mems.


- Ben


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


On Nov. 17, 2012, 11:13 p.m., Ben Mahler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8108/
> -----------------------------------------------------------
> 
> (Updated Nov. 17, 2012, 11:13 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Vinod Kone, and Jie Yu.
> 
> 
> Description
> -------
> 
> This is the first pass at adding cpuset isolation for pinning cgroups to cpus.
> 
> We decided to start with a simplistic grow/shrink allocation technique, as 
> such this initial technique:
>   -Does not take cache locality into account.
>   -Does not actively fight fragmentation*, but does a good job at preventing 
> it in many cases, given it's simplicity.
>   -Note that when cpus resource requests are integral (non-fractional), then 
> fragmentation does not occur.
> 
> *By fragmentation, I'm referring to the case where we've spread a cgroup over 
> more cpus than necessary, due to other cgroups sharing the same cpus.
> High fragmentation would mean a lot of shared cpus across cgroups.
> No fragmentation would mean each cgroup has a unique set of cpus.
> 
> I've punted on documenting the pitfalls of this technique, wiring up the 
> handler, and adding tests for now.
> 
> Note that this is diffed off of benh's changes:
> https://reviews.apache.org/r/8058/
> https://reviews.apache.org/r/8059/
> 
> 
> Diffs
> -----
> 
>   src/linux/proc.hpp 27e15bf8695aa694b0d5bdb6881b9fa55a447528 
>   src/slave/cgroups_isolation_module.hpp 
> 9f80fc5a969b959b34eaea4cac40700662d7f8b2 
>   src/slave/cgroups_isolation_module.cpp 
> 8211618d7729350654e2d17946c5b912ed9dda6a 
>   third_party/libprocess/include/stout/strings.hpp 
> 914c280a994733764957d19f37b48d151bb93778 
> 
> Diff: https://reviews.apache.org/r/8108/diff/
> 
> 
> Testing
> -------
> 
> None as of yet.
> 
> 
> Thanks,
> 
> Ben Mahler
> 
>

Reply via email to