On Fri, Dec 14, 2012 at 4:07 AM, Michal Hocko <mhocko@xxxxxxx> 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>