<snip> > > > > > It seems to me though the sizeof(zsdesc) is actually 56 bytes (on > > > > 64-bit), so sizeof(zsdesc) + sizeof(memdesc) would be equal to the > > > > current size of struct page. If that's true, then there is no loss, > > > > > > Yeah, zsdesc would be 56 bytes on 64 bit CPUs as memcg_data field is > > > not used in zsmalloc. > > > More fields in the current struct page might not be needed in the > > > future, although it's hard to say at the moment. > > > but it's not a loss. > > > > Is page->memcg_data something that we can drop? Aren't there code > > paths that will check page->memcg_data even for kernel pages (e.g. > > __folio_put() -> __folio_put_small() -> mem_cgroup_uncharge() ) ? > > zsmalloc pages are not accounted for via __GFP_ACCOUNT, Yeah, but the code in the free path above will check page->memcg_data nonetheless to check if it is charged. I think to drop memcg_data we need to enlighten the code that some pages do not even have memcg_data at all, no? > and IIUC the current implementation of zswap memcg charging does not > use memcg_data > either - so I think it can be dropped. My question is more about the generic mm code expecting to see page->memcg_data in every page, even if it is not actually used (zero). > > I think we don't want to increase memdesc to 16 bytes by adding memcg_data. > It should be in use-case specific descriptors if it can be charged to memcg? > <snip>
