> OK, as far as I can tell, this is introducing a per-node, per-memcg > LRU lists. Is that correct? > > If so, then that is not what Glauber and I originally intended for > memcg LRUs. per-node LRUs are expensive in terms of memory and cross > multiplying them by the number of memcgs in a system was not a good > use of memory. > > According to Glauber, most memcgs are small and typically confined > to a single node or two by external means and therefore don't need the > scalability numa aware LRUs provide. Hence the idea was that the > memcg LRUs would just be a single LRU list, just like a non-numa > aware list_lru instantiation. IOWs, this is the structure that we > had decided on as the best compromise between memory usage, > complexity and memcg awareness: > Sorry for jumping late into this particular e-mail. I just wanted to point out that the reason I adopted such matrix in my design was that it actually uses less memory this way. My reasoning for this was explained in the original patch that I posted that contained that implementation. This is because whenever an object would go on a memcg list, it *would not* go on the global list. Therefore, to keep information about nodes for global reclaim, you have to put them in node-lists. memcg reclaim, however, would reclaim regardless of node information. In global reclaim, the memcg lists would be scanned obeying the node structure in the lists. Because that has a fixed cost, it ends up using less memory that having a second list pointer in the objects, which is something that scale with the number of objects. Not to mention, that cost would be incurred even with memcg not being in use, which is something that we would like to avoid. -- 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>