Yo, On Wed, Jun 05, 2013 at 05:17:04PM -0400, Johannes Weiner wrote: > That could be an advantage, yes. But keep in mind that every > destruction has to perform this invalidation operation against the > global root_mem_cgroup's nr_node * nr_zone * nr_priority_levels > iterators, so you can't muck around forever, while possibly holding a > lock at this level. It's not a hot path, but you don't want to turn > it into one, either. nr_node tends to be pretty low in most cases, so it shouldn't be a problem there but yeah with high enough nodes and high enough rate of cgroup destruction, I guess it could be an issue in extreme cases. > The upshot for me is this: whether you do long-term pinning or greedy > iterator invalidation, the cost of cgroup destruction increases. > Either in terms of memory usage or in terms of compute time. I would > have loved to see something as simple as the long-term pinning work > out in practice, because it truly would have been simpler. But at > this point, I don't really care much because the projected margins of > reduction in complexity and increase of cost from your proposal are > too small for me to feel strongly about one solution or the other, or > go ahead and write the code. I'll look at your patches, though ;-) I don't know. I've developed this deep-seated distrust of any code which makes creative use of barriers and object lifetimes. We get them wrong too often, it makes other devs a lot more reluctant to review and dive into the code, and it's hellish to track down when something actually goes wrong. I'd happily pay a bit of computation or memory overhead for more conventional construct. In extremely hot paths, sure, we just bite and do it but I don't think this reaches that level. > Either way, I'll prepare the patch set that includes the barrier fix > and a small cleanup to make the weak pointer management more > palatable. I'm still open to code proposals, so don't let it distract > you, but we might as well make it a bit more readable in the meantime. Sure thing. We need to get it fixed for -stable anyway. 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>