Re: [mm][PATCH 0/4] Memory cgroup hierarchy introduction

Balbir Singh
2008-11-05T17:54:20Z

KAMEZAWA Hiroyuki wrote:
> 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.
>

For that sort of implementation, we'll need a common LRU. I actually thought of
implementing it by sharing a common LRU, but then we would end up with just one
common LRU at the root :)

The reclaim algorithm is smart in that it knows what pages are commonly
accessed. group A will get reclaimed more since those pages are not actively
referenced. reclaim on group_C will be harder. Simple experiments seem to show that.

>>> 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.

Let me get a good working version against current -mm and then we'll integrate
our patches.

--
Balbir