Re: [patch -v4 4/8] memcg: enhance memcg iterator to supportpredicates
From: Michal Hocko
Date: Tue Jun 04 2013 - 16:48:21 EST
On Tue 04-06-13 12:36:19, Tejun Heo wrote:
> Hey, Michal.
> On Tue, Jun 04, 2013 at 03:45:23PM +0200, Michal Hocko wrote:
> > Is this something that you find serious enough to block this series?
> > I do not want to push hard but I would like to settle with something
> > finally. This is taking way longer than I would like.
> I really don't think memcg can afford to add more mess than there
> already is. Let's try to get things right with each change, please.
Is this really about inside vs. outside skipping? I think this is a
general improvement to the code. I really prefer not duplicating common
code and skipping handling is such a code (we have a visitor which can
control the walk). With a side bonus that it doesn't have to pollute
vmscan more than necessary.
Please be more specific about _what_ is so ugly about this interface so
that it matters so much.
> Can we please see how the other approach would look like? I have a
> suspicion that it's likely be simpler but the devils are in the
> details and all...
> > > The iteration only depends on the current position. Can't you factor
> > > out skipping part outside the function rather than rolling into this
> > > monstery thing with predicate callback? Just test the condition
> > > outside and call a function to skip whatever is necessary?
> > >
> > > Also, cgroup_rightmost_descendant() can be pretty expensive depending
> > > on how your tree looks like.
> > I have no problem using something else. This was just the easiest to
> > use and it behaves more-or-less good for hierarchies which are more or
> > less balanced. If this turns out to be a problem we can introduce a
> > new cgroup_skip_subtree which would get to last->sibling or go up the
> > parent chain until there is non-NULL sibling. But what would be the next
> > selling point here if we made it perfect right now? ;)
> Yeah, sure thing. I was just worried because the skipping here might
> not be as good as the code seems to indicate. There will be cases,
> which aren't too uncommon, where the skipping doesn't save much
> compared to just continuing the pre-order walk, so.... And nobody
> would really notice it unless [s]he looks really hard for it, which is
> the more worrisome part for me. Maybe just stick a comment there
> explaining that we probably want something better in the future?
Sure thing. I will stick there a comment:
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 91740f7..43e955a 100644
@@ -1073,6 +1073,14 @@ skip_node:
prev_cgroup = next_cgroup;
+ * cgroup_rightmost_descendant is not an optimal way to
+ * skip through a subtree (especially for imbalanced
+ * trees leaning to right) but that's what we have right
+ * now. More effective solution would be traversing
+ * right-up for first non-NULL without calling
+ * cgroup_next_descendant_pre afterwards.
prev_cgroup = cgroup_rightmost_descendant(next_cgroup);
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/