Re: [PATCH V3 1/2] memcg: softlimit reclaim rework

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

(2012/04/21 8:15), Johannes Weiner wrote:

> On Fri, Apr 20, 2012 at 11:22:14AM -0700, Ying Han wrote:
>> On Fri, Apr 20, 2012 at 2:17 AM, Michal Hocko <mhocko@suse.cz> wrote:
>>> On Tue 17-04-12 09:38:02, Ying Han wrote:
>>>> This patch reverts all the existing softlimit reclaim implementations and
>>>> instead integrates the softlimit reclaim into existing global reclaim logic.
>>>>
>>>> The new softlimit reclaim includes the following changes:
>>>>
>>>> 1. add function should_reclaim_mem_cgroup()
>>>>
>>>> Add the filter function should_reclaim_mem_cgroup() under the common function
>>>> shrink_zone(). The later one is being called both from per-memcg reclaim as
>>>> well as global reclaim.
>>>>
>>>> Today the softlimit takes effect only under global memory pressure. The memcgs
>>>> get free run above their softlimit until there is a global memory contention.
>>>> This patch doesn't change the semantics.
>>>
>>> I am not sure I understand but I think it does change the semantics.
>>> Previously we looked at a group with the biggest excess and reclaim that
>>> group _hierarchically_.
>>
>> yes, we don't do _hierarchically_ reclaim reclaim in this patch. Hmm,
>> that might be what Johannes insists to preserve on the other
>> thread.... ?
> 
> Yes, that is exactly what I was talking about all along :-)
> 
> To reiterate, in the case of
> 
> A (soft = 10G)
>   A1
>   A2
>   A3
>   ...
> 
> global reclaim should go for A, A1, A2, A3, ... when their sum usage
> goes above 10G.  Regardless of any setting in those subgroups, for
> reasons I outlined in the other subthread (basically, allowing
> children to override parental settings assumes you trust all children
> and their settings to be 'cooperative', which is unprecedented cgroup
> semantics, afaics, and we can already see this will make problems in
> the future)
> 
> Meanwhile, if you don't want a hierarchical limit, don't set a
> hierarchical limit.  It's possible to organize the tree such that you
> don't need to, and it should not be an unreasonable amount of work to
> do so).
> 


I agree.


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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>