On Wed, May 20, 2020 at 11:51:51AM +0200, Vlastimil Babka wrote: > On 5/13/20 2:57 AM, Roman Gushchin wrote: > > > > Btw, I'm trying to build up a prototype with an embedded memcg pointer, > > but it seems to be way more tricky than I thought. It requires changes to > > shrinkers (as they rely on getting the memcg pointer by an arbitrary > > kernel address, not necessarily aligned to the head of slab allocation), > > figuring out cache merging, adding SLAB support, natural alignment of > > kmallocs etc. > > Is the natural alignment of kmallocs a problem right now? As kmalloc() > allocations are AFAIK not kmemcg-accounted? Or does your implementation add > memcg awareness to everything, even if non-__GFP_ACCOUNT allocations just get a > root memcg pointer? There is at least a dozen of accounted kmallocs as now, please search for kmalloc with GFP_KERNEL_ACCOUNT. Natural alignment is not an issue with the proposed implementation, but it becomes a problem as soon as we try to embed the memcg pointer into the object (as Christopher is suggesting). I'm actually not opposing his suggestion, just want to settle down the memcg part first, and then discuss the best way to store the memcg metadata information. As I shown, the required changes to switch between different ways of storing the data are minimal and do not affect the rest of the patchset. Thanks!
