Messages in this thread |  | | | Date | Thu, 6 Nov 2008 01:33:06 +0900 (JST) | | Subject | Re: [mm][PATCH 0/4] Memory cgroup hierarchy introduction | | From | "KAMEZAWA Hiroyuki" <> |
| |
Balbir Singh said: > KAMEZAWA Hiroyuki wrote: >> On Sun, 02 Nov 2008 00:18:12 +0530 >> Balbir Singh <balbir@linux.vnet.ibm.com> wrote: >> As first impression, I think hierarchical LRU management is not >> good...means >> not fair from viewpoint of memory management. > > Could you elaborate on this further? Is scanning of children during > reclaim the > issue? Do you want weighted reclaim for each of the children? > No. Consider follwing case /root/group_root/group_A /group_B /group_C
sum of group A, B, C is limited by group_root's limit.
Now, /group_root limit=1G, usage=990M /group_A usage=600M , no limit, no tasks for a while /group_B usage=10M , no limit, no tasks /group_C usage=380M , no limit, 2 tasks
A user run a new task in group_B. In your algorithm, group_A and B and C's memory are reclaimed to the same extent becasue there is no information to show "group A's memory are not accessed recently rather than B or C".
This information is what we want for managing memory.
>> I'd like to show some other possible implementation of >> try_to_free_mem_cgroup_pages() if I can. >> > > Elaborate please! > ok. but, at least, please add - per-subtree hierarchy flag. - cgroup_lock to walk list of cgroups somewhere.
I already sent my version "shared LRU" just as a hint for you. It is something extreme but contains something good, I think.
>> Anyway, I have to merge this with mem+swap controller. > > Cool! I'll send you an updated version. >
Synchronized LRU patch may help you.
Thanks, -Kame
|  |