From: kamezawa.hiroyu@jp.fujitsu.com
To: balbir@linux.vnet.ibm.com
Cc: kamezawa.hiroyu@jp.fujitsu.com, linux-mm@kvack.org,
LKML <linux-kernel@vger.kernel.org>,
xemul@openvz.org, menage@google.com, yamamoto@valinux.co.jp,
lizf@cn.fujitsu.com
Subject: Re: Re: [RFC][PATCH 1/2] memcg: res_counter hierarchy
Date: Sat, 31 May 2008 23:47:00 +0900 (JST) [thread overview]
Message-ID: <26479923.1212245220415.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <48413482.5080409@linux.vnet.ibm.com>
----- Original Message -----
>> 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 limi
ts
>is done with shares
>
Yes, I like _share_ rather than limits.
>If a parent has 100 shares, then it can decide how many to pass on to it's c
hildren
>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 th
e
>shares, deduce the limit of each node in the hierarchy.
>
>What do you think?
>
As you wrote, a middleware can do controls based on share by limits.
And it seems much easier to implement it in userland rather than in the kernel
.
Here is an example. (just an example...)
Please point out if I'm misunderstanding "share".
root_level/ = limit 1G.
/child_A = share=30
/child_B = share=15
/child_C = share=5
(and assume there is no process under root_level for make explanation easy..)
0. At first, before starting to use memory, set all kernel_memory_limit.
root_level.limit = 1G
child_A.limit=64M,usage=0
child_B.limit=64M,usage=0
child_C.limit=64M,usage=0
free_resource=808M
1. next, a process in child_C start to run and use memory of 600M.
root_level.limit = 1G
child_A.limit=64M
child_B.limit=64M
child_C.limit=600M,usage=600M
free_resource=272M
2. now, a process in child_A start tu run and use memory of 800M.
child_A.limit=800M,usage=800M
child_B.limit=64M,usage=0M
child_C.limit=136M,usage=136M
free_resouce=0,A:C=6:1
3.Finally, a process in child_B start. and use memory of 500M.
child_A.limit=600M,usage=600M
child_B.limit=300M,usage=300M
child_C.limit=100M,usage=100M
free_resouce=0, A:B:C=6:3:1
4. one more, a process in A exits.
child_A.limit=64M, usage=0M
child_B.limit=500M, usage=500M
child_C.limit=436M, usage=436M
free_resouce=0, B:C=3:1 (but B just want to use 500M)
This is only an example and the middleware can more pricise "limit"
contols by checking statistics of memory controller hierarchy based on
their own policy.
What I think now is what kind of statistics/notifier/controls are
necessary to implement shares in middleware. How pricise/quick work the
middleware can do is based on interfaces.
Maybe the middleware should know "how fast the application runs now" by
some kind of check or co-operative interface with the application.
But I'm not sure how the kernel can help it.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-05-31 14:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-30 1:43 [RFC][PATCH 0/2] memcg: simple hierarchy (v2) KAMEZAWA Hiroyuki
2008-05-30 1:45 ` [RFC][PATCH 1/2] memcg: res_counter hierarchy KAMEZAWA Hiroyuki
2008-05-30 22:20 ` Balbir Singh
2008-05-31 1:59 ` kamezawa.hiroyu
2008-05-31 11:20 ` Balbir Singh
2008-05-31 14:47 ` kamezawa.hiroyu [this message]
2008-05-31 17:18 ` Balbir Singh
2008-06-01 0:35 ` kamezawa.hiroyu
2008-06-02 6:16 ` Balbir Singh
2008-06-02 9:48 ` kamezawa.hiroyu
2008-06-02 2:15 ` YAMAMOTO Takashi
2008-06-02 9:52 ` kamezawa.hiroyu
2008-05-30 1:46 ` [RFC][PATCH 2/2] memcg: memcg hierarchy KAMEZAWA Hiroyuki
2008-05-30 1:46 ` [RFC][PATCH 0/2] memcg: simple hierarchy (v2) Rik van Riel
2008-06-09 10:37 [RFC][PATCH 1/2] memcg: res_counter hierarchy Balbir Singh
2008-06-04 4:58 ` [RFC][PATCH 0/2] memcg: hierarchy support (v3) KAMEZAWA Hiroyuki
2008-06-04 5:01 ` [RFC][PATCH 1/2] memcg: res_counter hierarchy KAMEZAWA Hiroyuki
2008-06-09 9:48 ` Balbir Singh
2008-06-09 10:20 ` KAMEZAWA Hiroyuki
2008-06-09 12:02 ` kamezawa.hiroyu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26479923.1212245220415.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.com \
--cc=xemul@openvz.org \
--cc=yamamoto@valinux.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox