Re: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- From: kamezawa.hiroyu@xxxxxxxxxxxxxx
- Date: Sat, 31 May 2008 10:59:16 +0900 (JST)
KAMEZAWA Hiroyuki wrote:sary
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
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.
aimworks 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
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.
As explained, this can be dynamic by middleware.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
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.
Thanks,
-Kame
--
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/
- Follow-Ups:
- Re: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- From: kamezawa . hiroyu
- Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- From: Balbir Singh
- Re: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- References:
- Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- From: Balbir Singh
- [RFC][PATCH 0/2] memcg: simple hierarchy (v2)
- From: KAMEZAWA Hiroyuki
- [RFC][PATCH 1/2] memcg: res_counter hierarchy
- From: KAMEZAWA Hiroyuki
- Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- Prev by Date: Re: [PATCH] sysctl: allow override of /proc/sys/net with CAP_NET_ADMIN
- Next by Date: Re: [PATCH] net: add ability to clear stats via ethtool - e1000/pcnet32
- Previous by thread: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- Next by thread: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
- Index(es):
Relevant Pages
|