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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux