Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller

[Rohit Seth <rohitseth@google.com>]

On Mon, 2006-08-07 at 20:33 +0400, Kirill Korotaev wrote:
> >> we already have the code to account page fractions shared between 
> >> containers.
> >> Though, it is quite useless to do so for threads... Since this numbers 
> >> have no meaning (not a real usage)
> >> and only the sum of it will be a correct value.
> >>
> > THat sort of accounting poses various horrible problems, which is
> > why we steered away from it. If you share pages between containers
> > (presumably billing them equal shares per user), what happens
> > when you're already at your limit, and one of your sharer's exits?
> you come across your limit and new allocations will fail.
> BUT! IMPORTANT!
> in real life use case with OpenVZ we allow sharing not that much data across containers:
> vmas mapped as private, i.e. glibc and other libraries .data section
> (and .code if it is writable). So if you use the same glibc and other executables
> in the containers then your are charged only a fraction of phys memory used by it.
> This kind of sharing is not that huge (<< memory limits usually),
> so the situation you described is not a problem
> in real life (at least for OpenVZ).
> 

I think it is not a problem for OpenVZ because there is not that much of
sharing going between containers as you mentioned (btw, this least
amount of sharing is a very good thing).  Though I'm not sure if one has
to go to the extent of doing fractions with memory accounting.  If the
containers are set up in such a way that there is some sharing across
containers then it is okay to be unfair and charge one of those
containers for the specific resource completely.

-rohit

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/