[mm v2 0/3] Support memory cgroup hotplug

Michal Hocko mhocko at kernel.org
Wed Nov 23 19:07:45 AEDT 2016


On Wed 23-11-16 18:50:42, Balbir Singh wrote:
> 
> 
> On 23/11/16 18:25, Michal Hocko wrote:
> > On Wed 23-11-16 15:36:51, Balbir Singh wrote:
> >> In the absence of hotplug we use extra memory proportional to
> >> (possible_nodes - online_nodes) * number_of_cgroups. PPC64 has a patch
> >> to disable large consumption with large number of cgroups. This patch
> >> adds hotplug support to memory cgroups and reverts the commit that
> >> limited possible nodes to online nodes.
> > 
> > Balbir,
> > I have asked this in the previous version but there still seems to be a
> > lack of information of _why_ do we want this, _how_ much do we save on
> > the memory overhead on most systems and _why_ the additional complexity
> > is really worth it. Please make sure to add all this in the cover
> > letter.
> > 
> 
> The data is in the patch referred to in patch 3. The order of waste was
> 200MB for 400 cgroup directories enough for us to restrict possible_map
> to online_map. These patches allow us to have a larger possible map and
> allow onlining nodes not in the online_map, which is currently a restriction
> on ppc64.

How common is to have possible_map >> online_map? If this is ppc64 then
what is the downside of keeping the current restriction instead?

> A typical system that I use has about 100-150 directories, depending on the
> number of users/docker instances/configuration/virtual machines. These numbers
> will only grow as we pack more of these instances on them.
> 
> From a complexity view point, the patches are quite straight forward.

Well, I would like to hear more about that. {get,put}_online_memory
at random places doesn't sound all that straightforward to me.

-- 
Michal Hocko
SUSE Labs


More information about the Linuxppc-dev mailing list