Hi. On the MM sessions I'd like to participate in the memcg discussions. Topics that are of the most interest to me are: * kernel memory accounting * dirty set management * VM overcommit management * LRU lists management The first two issues are already described in respectively [1] and [2]. The 3rd issue was raised many times on the mailing lists, but I haven't seen whether it was resolved finally and would like to bring it up again. Now about the 4th one (LRU lists management). The existing memcg model uses page_cgroup object to track the page to memcg relation. Each page that belongs to some memcg has that object allocated. Such a design doesn't look very elegant from my POV, provides a memory overhead and makes the mm/vmscan.c code looks not very nice, since each page lives in up to two LRU lists :\ I wanted to propose the scheme used in the OpenVZ RHEL6-based kernel [3]. Briefly - in that scheme we introduce a lru_lists object which contains the LRU list heads and statistics for that lists and each page belong so some lru_list. A new memcg should allocate and use its own new lru_list. [1] http://marc.info/?l=linux-mm&m=129686460401990 [2] http://marc.info/?l=linux-mm&m=129684641013000 [3] http://community.livejournal.com/openvz/34522.html -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>