Messages in this thread | | | Subject | Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller | From | Rohit Seth <> | Date | Mon, 07 Aug 2006 11:31:26 -0700 |
| |
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/
| |