[LSF/MM TOPIC] Kernel memory tracking in memcg

[Suleiman Souhlal <suleiman@google.com>]

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@kvack.org.  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@kvack.org"> email@kvack.org </a>