Hey, again. On Fri, Jan 30, 2015 at 01:27:37AM -0500, Tejun Heo wrote: > The previous behavior was pretty unpredictable in terms of shared file > ownership too. I wonder whether the better thing to do here is either > charging cases like this to the common ancestor or splitting the > charge equally among the accessors, which might be doable for ro > files. I've been thinking more about this. It's true that doing per-page association allows for avoiding confronting the worst side effects of inode sharing head-on, but it is a tradeoff with fairly weak justfications. The only thing we're gaining is side-stepping the blunt of the problem in an awkward manner and the loss of clarity in taking this compromised position has nasty ramifications when we try to connect it with the rest of the world. I could be missing something major but the more I think about it, it looks to me that the right thing to do here is accounting per-inode and charging shared inodes to the nearest common ancestor. The resulting behavior would be way more logical and predicatable than the current one, which would make it straight forward to integrate memcg with blkcg and writeback. One of the problems that I can think of off the top of my head is that it'd involve more regular use of charge moving; however, this is an operation which is per-inode rather than per-page and still gonna be fairly infrequent. Another one is that if we move memcg over to this behavior, it's likely to affect the behavior on the traditional hierarchies too as we sure as hell don't want to switch between the two major behaviors dynamically but given that behaviors on inode sharing aren't very well supported yet, this can be an acceptable change. 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>