Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy

kamezawa.hiroyu@xxxxxxxxxxxxxx wrote:
KAMEZAWA Hiroyuki wrote:
This patch tries to implements _simple_ 'hierarchy policy' in res_counter.

While several policy of hierarchy can be considered, this patch implements
simple one
- the parent includes, over-commits the child
- there are no shared resource
I am not sure if this is desirable. The concept of a hierarchy applies really
well when there are shared resources.

- dynamic hierarchy resource usage management in the kernel is not neces
sary
Could you please elaborate as to why? I am not sure I understand your point


ok, let's consider a _miiddleware_ wchich has following paramater.

An expoterd param to the user.
- user_memory_limit
parameters for co-operation with the kernel
- kernel_memory_limit

And here,
user_memory_limit >= kernel_memory_limit == cgroup's memory.limits_in_bytes

When a user ask the miidleware to set limit to 1Gbytes
user_memory_limit = 1G
kernel_memory_limit = 0-1G.
It moves kernel_memory_limit dynamically 0 to 1Gbytes and reset limits_in_byte
s in dynamic way with checking memory cgroup's statistics.
Of course, we can add some kind of interdace , as following
- failure_notifier - triggered at failcnt increment.
- threshhold_notifier - triggered as usage > threshold.

works as following.

1. create a child. set default child limits to be 0.
2. set limit to child.
2-a. before setting limit to child, prepare enough room in parent.
2-b. increase 'usage' of parent by child's limit.
The problem with this is that you are forcing the parent will run into a recl
aim
loop even if the child is not using the assigned limit to it.

That's not problem because it's avoildable by users.
But it's ok to limit the sum of child's limit to be below XX % ot the parent.

3. the child sets its limit to the val moved from the parent.
the parent remembers what amount of resource is to the children.

All of this needs to be dynamic

As explained, this can be dynamic by middleware.

Above means that
- a directory's usage implies the sum of all sub directories +
own usage.
- there are no shared resource between parent <-> child.

Pros.
- simple and easy policy.
- no hierarchy overhead.
- no resource share among child <-> parent. very suitable for multilevel
resource isolation.
Sharing is an important aspect of hierachies. I am not convinced of this
approach. Did you look at the patches I sent out? Was there something
fundamentally broken in them?


Yes, I read. And tried to make it faster and found it will be complicated.
One problem is overhead of counter itself.
Another problem is overhead of shrinking multi-level LRU with feedback.
One more problem is that it's hard to implement various kinds of hierarchy
policy. I believe there are other hierarhcy policies rather than OpenVZ
want to use. Kicking out functions to middleware AMAP is what I'm thinking
now.

One way to manage hierarchies other than via limits is to use shares (please see
the shares used by the cpu controller). Basically, what you've done with limits
is done with shares

If a parent has 100 shares, then it can decide how many to pass on to it's children
based on the shares of the child and your logic would work well. I propose
assigning top level (high resolution) shares to the root of the cgroup and in a
hierarchy passing them down to children and sharing it with them. Based on the
shares, deduce the limit of each node in the hierarchy.

What do you think?


--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: SQL, related records (quotes)
    ... Let's say for the hierarchy itself we decide on ... child parent ... child B to reference for referential integrity and what meaning the ... possible with a vertex involving itself as a root node of a hierarchy. ...
    (comp.databases.theory)
  • Re: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
    ... While several policy of hierarchy can be considered, ... there are no shared resource ... create a child. ... prepare enough room in parent. ...
    (Linux-Kernel)
  • [RFC][PATCH 1/2] memcg: res_counter hierarchy
    ... This patch tries to implements _simple_ 'hierarchy policy' in res_counter. ... dynamic hierarchy resource usage management in the kernel is not necessary ... create a child. ... prepare enough room in parent. ...
    (Linux-Kernel)
  • object hierarchy, parent-child links, etc
    ... I am trying to construct an object hierarchy for some relatively simple ... objects I am trying to expose to COM / Automation for use in scripting. ... in which the parent has one statically-created child member. ...
    (microsoft.public.vc.atl)
  • Re: [9fans] _tos puzzle
    ... Linux shares the stack segment too: the underlying system call shares everything, ... rfork by contrast shares data and dss, but gives parent and child private copies of the stack. ...
    (comp.os.plan9)