On Jul 16, 2009, at 10:15 AM, Balbir Singh wrote:
> Dan, if you are suggesting that we incrementally add features, I
> completely agree with you, that way the code is reviewable and
> maintainable. As we add features we need to
Right, this is all goodness. My specific comments are this patch
adds a new useful feature and it's been through a couple of iterations
to make it more acceptable. Let's post it, as it makes people aware
of such a feature since it's currently in use and useful, and then
continue the discussion about how to make it (and all of the cgroup
features) better. Otherwise, this is going to degenerate into a "do
everything but nothing gets done" ongoing discussion and I'll
quickly lose interest and move on the something else :-)
There are currently two discussions in progress. One is about
notification limits, which this feature patch adds. We need to
close this discussion with a more feature rich implementation
that addresses both upper and lower notification, the semantics
of this feature in a cgroup hierarchy, and in particular the
behavior outside of the memory controller group.
The second discussion is about event delivery in cgroups.
Linux already has many mechanisms, and some product
implementations patch even more of their own into the kernel.
Outside of these implementation details, we have to determine
what is useful for a cgroup. Are events just arbitrary (anything
can send any kind of event)? How do we pass information?
Is there some standard header? How do we control this so
the event target is identified and we prevent event floods?
And many more.....
> 1. Look at reuse
> 2. Make sure the design is sane and will not prohibit further
> development.
3. Contain the scope of work so I can do it without affecting
the work that pays my salary :-)
Thanks.
-- Dan
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
