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

[Kirill Korotaev <dev@sw.ru>]

> > 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.
In this case you can't plan your resources, can't say which one consumes
more memory and can't select the worst container to kill and many other drawbacks.

Kirill

-
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/