Hey, Johannes. On Wed, Jun 05, 2013 at 10:39:49AM -0400, Johannes Weiner wrote: > 5k cgroups * say 10 priority levels * 1k struct mem_cgroup may pin 51M > of dead struct mem_cgroup, plus whatever else the css pins. Yeah, it seems like it can grow quite a bit. > > I'll get to the barrier thread but really complex barrier dancing like > > that is only justifiable in extremely hot paths a lot of people pay > > attention to. It doesn't belong inside memcg proper. If the cached > > amount is an actual concern, let's please implement a simple clean up > > thing. All we need is a single delayed_work which scans the tree > > periodically. > > > > Johannes, what do you think? > > While I see your concerns about complexity (and this certainly is not > the most straight-forward code), I really can't get too excited about > asynchroneous garbage collection, even worse when it's time-based. It > would probably start out with less code but two releases later we > would have added all this stuff that's required to get the interaction > right and fix unpredictable reclaim disruption that hits when the > reaper coincides just right with heavy reclaim once a week etc. I > just don't think that asynchroneous models are simpler than state > machines. Harder to reason about, harder to debug. Agreed, but we can do the cleanup from ->css_offline() as Michal suggested. Naively implemented, this will lose the nice property of keeping the iteration point even when the cursor cgroup is removed, which can be an issue if we're actually worrying about cases with 5k cgroups continuously being created and destroyed. Maybe we can make it point to the next cgroup to visit rather than the last visited one and update it from ->css_offline(). > Now, there are separate things that add complexity to our current > code: the weak pointers, the lockless iterator, and the fact that all > of it is jam-packed into one monolithic iterator function. I can see > why you are not happy. But that does not mean we have to get rid of > everything wholesale. > > You hate the barriers, so let's add a lock to access the iterator. > That path is not too hot in most cases. > > On the other hand, the weak pointer is not too esoteric of a pattern > and we can neatly abstract it into two functions: one that takes an > iterator and returns a verified css reference or NULL, and one to > invalidate pointers when called from the memcg destruction code. > > These two things should greatly simplify mem_cgroup_iter() while not > completely abandoning all our optimizations. > > What do you think? I really think the weak pointers should go especially as we can achieve about the same thing with normal RCU dereference. Also, I'm a bit confused about what you're suggesting. If we have invalidation from offline, why do we need weak pointers? Thanks. -- tejun -- 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>