Hi, Currently, memcg only tracks user memory. However, some workloads can cause heavy kernel memory use (for example, when doing a lot of network I/O), which would ideally be counted towards the limit in memory cgroup. Without this, memory isolation could be damaged, as one cgroup using a lot of kernel memory could penalize other cgroups by causing global reclaim on the machine. Things that could potentially be discussed: - Should all kinds of kernel allocations be accounted (get_free_pages, slab, vmalloc)? - Should every allocation done in a process context be accounted? - Should kernel memory be counted towards the memcg limit, or should a different limit be used? - Implementation. Is this worth discussing? [ My initial thoughts on the issue: Slab makes for the bulk of kernel allocations, and any solution would need a slab component, so it's a good starting point. Also, most kernel allocations in process context belong to that process (although there are some exceptions), so it should be mostly ok to account every allocation in process context. For slab, we can do tracking per slab (instead of per-object), by making sure objects from a slab are only used by one cgroup. ] -- Suleiman -- 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>