Hello, Michal. On Tue, Jun 04, 2013 at 11:28:08PM +0200, Michal Hocko wrote: > Well, I do not mind pinning when I know that somebody releases the > reference in a predictable future (ideally almost immediately). But the > cached iter represents time unbounded pinning because nobody can > guarantee that priority 3 at zone Normal at node 3 will be ever scanned > again and the pointer in the last_visited node will be stuck there for I don't really get that. As long as the amount is bound and the overhead negligible / acceptable, why does it matter how long the pinning persists? We aren't talking about something gigantic or can leak continuously. It will only matter iff cgroups are continuously created and destroyed and each live memcg will be able to pin one memcg (BTW, I think I forgot to unpin on memcg destruction). > eternity. Can we free memcg with only css elevated and safely check that > the cached pointer can be used without similar dances we have now? > I am open to any suggestions. I really think this is worrying too much about something which doesn't really matter and then coming up with an over-engineered solution for the imagined problem. This isn't a real problem. No solution is necessary. In the off chance that this is a real problem, which I strongly doubt, as I wrote to Johannes, we can implement extremely dumb cleanup routine rather than this weak reference beast. 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>