Re: [RFC 1/3] memcg: integrate soft reclaim tighter with zone shrinking code

[Johannes Weiner <hannes@cmpxchg.org>]

On Sun, Apr 14, 2013 at 07:34:20AM -0700, Michal Hocko wrote:
> On Sun 14-04-13 01:42:52, Mel Gorman wrote:
> > On Tue, Apr 09, 2013 at 02:13:13PM +0200, Michal Hocko wrote:
> > > @@ -1961,6 +1973,13 @@ static void shrink_zone(struct zone *zone, struct scan_control *sc)
> > >  		do {
> > >  			struct lruvec *lruvec;
> > >  
> > > +			if (soft_reclaim &&
> > > +					!mem_cgroup_soft_reclaim_eligible(memcg)) {
> > > +				memcg = mem_cgroup_iter(root, memcg, &reclaim);
> > > +				continue;
> > > +			}
> > > +
> > 
> > Calling mem_cgroup_soft_reclaim_eligible means we do multiple searches
> > of the hierarchy while ascending the hierarchy. It's a stretch but it
> > may be a problem for very deep hierarchies.
> 
> I think it shouldn't be a problem for hundreds of memcgs and I am quite
> sceptical about such configurations for other reasons (e.g. charging
> overhead). And we are in the reclaim path so this is hardly a hot path
> (unlike the chargin). So while this might turn out to be a real problem
> we would need to fix other parts as well with higher priority.
> 
> > Would it be worth having mem_cgroup_soft_reclaim_eligible return what
> > the highest parent over its soft limit was and stop the iterator when
> > the highest parent is reached?  I think this would avoid calling
> > mem_cgroup_soft_reclaim_eligible multiple times.
> 
> This is basically what the original implementation did and I think it is
> not the right way to go. First why should we care who is the most
> exceeding group. We should treat them equally if the there is no special
> reason to not do so. And I do not see such a special reason. Besides
> that keeping a exceed sorted data structure of memcgs turned out quite a
> lot of code. Note that the later patch integrate soft reclaim into
> targeted reclaim which would mean that we would have to keep such a
> list/tree per memcg.

I think what Mel suggests is not to return the highest excessor, but
return the highest parent in the hierarchy that is in excess.  Once
you have this parent, you know that all children are in excess,
without looking them up individually.

However, that parent is not necessarily the root of the hierarchy that
is being reclaimed and you might have multiple of such sub-hierarchies
in excess.  To handle all the corner cases, I'd expect the
relationship checking to get really complicated.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>