On Thu, Jan 30, 2020 at 07:36:26AM +0530, Bharata B Rao wrote: > On Mon, Jan 27, 2020 at 09:34:25AM -0800, Roman Gushchin wrote: > > The existing cgroup slab memory controller is based on the idea of > > replicating slab allocator internals for each memory cgroup. > > This approach promises a low memory overhead (one pointer per page), > > and isn't adding too much code on hot allocation and release paths. > > But is has a very serious flaw: it leads to a low slab utilization. > > > > Using a drgn* script I've got an estimation of slab utilization on > > a number of machines running different production workloads. In most > > cases it was between 45% and 65%, and the best number I've seen was > > around 85%. Turning kmem accounting off brings it to high 90s. Also > > it brings back 30-50% of slab memory. It means that the real price > > of the existing slab memory controller is way bigger than a pointer > > per page. > > > > The real reason why the existing design leads to a low slab utilization > > is simple: slab pages are used exclusively by one memory cgroup. > > If there are only few allocations of certain size made by a cgroup, > > or if some active objects (e.g. dentries) are left after the cgroup is > > deleted, or the cgroup contains a single-threaded application which is > > barely allocating any kernel objects, but does it every time on a new CPU: > > in all these cases the resulting slab utilization is very low. > > If kmem accounting is off, the kernel is able to use free space > > on slab pages for other allocations. > > > > Arguably it wasn't an issue back to days when the kmem controller was > > introduced and was an opt-in feature, which had to be turned on > > individually for each memory cgroup. But now it's turned on by default > > on both cgroup v1 and v2. And modern systemd-based systems tend to > > create a large number of cgroups. > > > > This patchset provides a new implementation of the slab memory controller, > > which aims to reach a much better slab utilization by sharing slab pages > > between multiple memory cgroups. Below is the short description of the new > > design (more details in commit messages). > > > > Accounting is performed per-object instead of per-page. Slab-related > > vmstat counters are converted to bytes. Charging is performed on page-basis, > > with rounding up and remembering leftovers. > > > > Memcg ownership data is stored in a per-slab-page vector: for each slab page > > a vector of corresponding size is allocated. To keep slab memory reparenting > > working, instead of saving a pointer to the memory cgroup directly an > > intermediate object is used. It's simply a pointer to a memcg (which can be > > easily changed to the parent) with a built-in reference counter. This scheme > > allows to reparent all allocated objects without walking them over and > > changing memcg pointer to the parent. > > > > Instead of creating an individual set of kmem_caches for each memory cgroup, > > two global sets are used: the root set for non-accounted and root-cgroup > > allocations and the second set for all other allocations. This allows to > > simplify the lifetime management of individual kmem_caches: they are > > destroyed with root counterparts. It allows to remove a good amount of code > > and make things generally simpler. > > > > The patchset* has been tested on a number of different workloads in our > > production. In all cases it saved significant amount of memory, measured > > from high hundreds of MBs to single GBs per host. On average, the size > > of slab memory has been reduced by 35-45%. > > Here are some numbers from multiple runs of sysbench and kernel compilation > with this patchset on a 10 core POWER8 host: > > ========================================================================== > Peak usage of memory.kmem.usage_in_bytes, memory.usage_in_bytes and > meminfo:Slab for Sysbench oltp_read_write with mysqld running as part > of a mem cgroup (Sampling every 5s) > -------------------------------------------------------------------------- > 5.5.0-rc7-mm1 +slab patch %reduction > -------------------------------------------------------------------------- > memory.kmem.usage_in_bytes 15859712 4456448 72 > memory.usage_in_bytes 337510400 335806464 .5 > Slab: (kB) 814336 607296 25 > > memory.kmem.usage_in_bytes 16187392 4653056 71 > memory.usage_in_bytes 318832640 300154880 5 > Slab: (kB) 789888 559744 29 > -------------------------------------------------------------------------- > > > Peak usage of memory.kmem.usage_in_bytes, memory.usage_in_bytes and > meminfo:Slab for kernel compilation (make -s -j64) Compilation was > done from bash that is in a memory cgroup. (Sampling every 5s) > -------------------------------------------------------------------------- > 5.5.0-rc7-mm1 +slab patch %reduction > -------------------------------------------------------------------------- > memory.kmem.usage_in_bytes 338493440 231931904 31 > memory.usage_in_bytes 7368015872 6275923968 15 > Slab: (kB) 1139072 785408 31 > > memory.kmem.usage_in_bytes 341835776 236453888 30 > memory.usage_in_bytes 6540427264 6072893440 7 > Slab: (kB) 1074304 761280 29 > > memory.kmem.usage_in_bytes 340525056 233570304 31 > memory.usage_in_bytes 6406209536 6177357824 3 > Slab: (kB) 1244288 739712 40 > -------------------------------------------------------------------------- > > Slab consumption right after boot > -------------------------------------------------------------------------- > 5.5.0-rc7-mm1 +slab patch %reduction > -------------------------------------------------------------------------- > Slab: (kB) 821888 583424 29 > ========================================================================== > > Summary: > > With sysbench and kernel compilation, memory.kmem.usage_in_bytes shows > around 70% and 30% reduction consistently. > > Didn't see consistent reduction of memory.usage_in_bytes with sysbench and > kernel compilation. > > Slab usage (from /proc/meminfo) shows consistent 30% reduction and the > same is seen right after boot too. That's just perfect! memory.usage_in_bytes was most likely the same because the freed space was taken by pagecache. Thank you very much for testing! Roman
