> On Nov. 20, 2012, 8:05 p.m., Vinod Kone wrote: > > src/slave/cgroups_isolation_module.hpp, line 66 > > <https://reviews.apache.org/r/8108/diff/2-3/?file=221930#file221930line66> > > > > How about "Returns the total cpu usage across all the cpus in this cpu > > set" ?
done > On Nov. 20, 2012, 8:05 p.m., Vinod Kone wrote: > > src/slave/cgroups_isolation_module.cpp, line 99 > > <https://reviews.apache.org/r/8108/diff/2-3/?file=221931#file221931line99> > > > > s/slave doesn't not consider more cpus available/slave doesn't offer > > more cpus/ ? killed this TODO entirely in the new diff (since I added the check) > On Nov. 20, 2012, 8:05 p.m., Vinod Kone wrote: > > src/slave/cgroups_isolation_module.cpp, line 114 > > <https://reviews.apache.org/r/8108/diff/2-3/?file=221931#file221931line114> > > > > avoid? > > > > I think this algorithm (shrink()) doesn't impact fragmentation at all, > > because of the way you do grow()? I'd argue grow() brings about the fragmentation, and shrink does a attempt to reduce it. Suppose shrink were to pull off from the first cpu we have allocated (akin to grow()), then we'd definitely fragment more! It's currently trying to reduce cpus.size() as much as possible. - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8108/#review13642 ----------------------------------------------------------- On Nov. 20, 2012, 7:32 p.m., Ben Mahler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8108/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2012, 7:32 p.m.) > > > Review request for mesos, Benjamin Hindman and Vinod Kone. > > > 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/stringify.hpp > dcc5b95a54e6f34f93867e015d8c855fd7d6f950 > third_party/libprocess/include/stout/strings.hpp > 914c280a994733764957d19f37b48d151bb93778 > > Diff: https://reviews.apache.org/r/8108/diff/ > > > Testing > ------- > > None as of yet. > > > Thanks, > > Ben Mahler > >
