lkml.org 
[lkml]   [2012]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [patch v2 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators
From
On Fri, Dec 14, 2012 at 4:07 AM, Michal Hocko <mhocko@suse.cz> wrote:
> On Thu 13-12-12 17:14:13, Ying Han wrote:
> [...]
>> I haven't tried this patch set yet. Before I am doing that, I am
>> curious whether changing the target reclaim to be consistent with
>> global reclaim something worthy to consider based my last reply:
>>
>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>> index 53dcde9..3f158c5 100644
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -1911,20 +1911,6 @@ static void shrink_zone(struct zone *zone,
>> struct scan_control *sc)
>>
>> shrink_lruvec(lruvec, sc);
>>
>> - /*
>> - * Limit reclaim has historically picked one memcg and
>> - * scanned it with decreasing priority levels until
>> - * nr_to_reclaim had been reclaimed. This priority
>> - * cycle is thus over after a single memcg.
>> - *
>> - * Direct reclaim and kswapd, on the other hand, have
>> - * to scan all memory cgroups to fulfill the overall
>> - * scan target for the zone.
>> - */
>> - if (!global_reclaim(sc)) {
>> - mem_cgroup_iter_break(root, memcg);
>> - break;
>> - }
>> memcg = mem_cgroup_iter(root, memcg, &reclaim);
>
> This wouldn't work because you would over-reclaim proportionally to the
> number of groups in the hierarchy.

Don't get it and especially of why it is different from global
reclaim? I view the global reclaim should be viewed as target reclaim,
just a matter of the root cgroup is under memory pressure.

Anyway, don't want to distract you from working on the next post. So
feel free to not follow up on this.

--Ying

>
>> } while (memcg);
>> }
>>
>> --Ying
>
> --
> Michal Hocko
> SUSE Labs


\
 
 \ /
  Last update: 2012-12-15 02:21    [W:0.073 / U:0.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site