On Mon, Apr 27, 2020 at 09:46:38AM -0700, Roman Gushchin wrote: > On Mon, Apr 27, 2020 at 04:21:01PM +0000, Christoph Lameter wrote: > > On Fri, 24 Apr 2020, Roman Gushchin wrote: > > > > > > The patch seems to only use it for setup and debugging? It is used for > > > > every "accounted" allocation???? Where? And what is an "accounted" > > > > allocation? > > > > > > > > > > > > > > Please, take a look at the whole series: > > > https://lore.kernel.org/linux-mm/[email protected]/T/#t > > > > > > I'm sorry, I had to cc you directly for the whole thing. Your feedback > > > will be highly appreciated. > > > > > > It's used to calculate the offset of the memcg pointer for every slab > > > object which is charged to a memory cgroup. So it must be quite hot. > > > > > > Ahh... Thanks. I just looked at it. > > > > You need this because you have a separate structure attached to a page > > that tracks membership of the slab object to the cgroup. This is used to > > calculate the offset into that array.... > > > > Why do you need this? Just slap a pointer to the cgroup as additional > > metadata onto the slab object. Is that not much simpler, safer and faster? > > > > So, the problem is that not all slab objects are accounted, and sometimes > we don't know if advance if they are accounted or not (with the current > semantics > of __GFP_ACCOUNT and SLAB_ACCOUNT flags). So we either have to increase > the size of ALL slab objects, either create a pair of slab caches for each > size.
Both options seem completely disproportionate in their memory cost, and the latter one in terms of code complexity, to avoid the offset calculation. As a share of the total object accounting cost, I'd expect this to be minimal. Does the mult stand out in an annotated perf profile? Is it enough to bring back 500+ lines of code, an additional branch on accounted allocations, and the memory fragmentation of split caches? I highly doubt it.
