On Fri 03-08-12 09:28:22, Ying Han wrote:
> On Fri, Aug 3, 2012 at 7:02 AM, Michal Hocko <mhocko@xxxxxxx> wrote:
> > On Thu 02-08-12 14:24:24, Ying Han wrote:
[...]
> >> diff --git a/mm/vmscan.c b/mm/vmscan.c
> >> index 88487b3..8622022 100644
> >> --- a/mm/vmscan.c
> >> +++ b/mm/vmscan.c
[...]
> >> @@ -1879,10 +1883,15 @@ static void shrink_zone(struct zone *zone, struct scan_control *sc)
> >> * we have to reclaim under softlimit instead of burning more
> >> * cpu cycles.
> >> */
> >> - if (!global_reclaim(sc) || sc->priority < DEF_PRIORITY ||
> >> - mem_cgroup_over_soft_limit(memcg))
> >> + if (ignore_softlimit || !global_reclaim(sc) ||
> >> + sc->priority < DEF_PRIORITY ||
> >> + mem_cgroup_over_soft_limit(memcg)) {
> >> shrink_lruvec(lruvec, sc);
> >>
> >> + if (!mem_cgroup_is_root(memcg))
> >> + over_softlimit = true;
> >> + }
> >> +
> >
> > I think this is still not sufficient because you do not want to hammer
> > root in the ignore_softlimit case.
>
> Are you worried about over-reclaiming from root cgroup while the rest
> of the cgroup are under softimit?
yes
> Hmm.. That only affect the DEF_PRIORITY level, and not sure how bad it
> is.
Even if it was for DEF_PRIORITY it would mean that the root group is
second class citizen which is definitely not good.
> On the other hand, I wonder if it is necessary bad since the pages
> under root cgroup are mainly re-parented pages which only get chance
> to be reclaimed under global pressure.
Hmm, I do not think this is true in general and you shouldn't rely on
it.
>
> --Ying
>
> > --
> > Michal Hocko
> > SUSE Labs
--
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>