On Wed, Mar 20, 2024 at 1:49 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > Hey folks, > > I was looking at cleaning up the same-filled handling code in zswap, > when it hit me that after the xarray conversion, the only member of > struct zwap_entry that is relevant to same-filled pages is now the > objcg pointer. > > The xarray allows a pointer to be tagged by up to two tags (1 and 3), > so we can completely avoid allocating a zswap_entry for same-filled > pages by storing a tagged objcg pointer directly in the xarray > instead. > > Basically the xarray would then either have a pointer to struct > zswap_entry or struct obj_cgroup, where the latter is tagged as > SAME_FILLED_ONE or SAME_FILLED_ZERO. > > There are two benefits of this: > - Saving some memory (precisely 64 bytes per same-filled entry). > - Further separating handling of same-filled pages from compressed > pages, which results in some nice cleanups (especially in > zswap_store()). It also makes further improvements easier (e.g. > skipping limit checking for same-filled entries). > > The disadvantage is obviously the complexity needed to handle two > different types of pointers in the xarray, although I think with the > correct abstractions this is not a big deal. Another idea is we can make the zero fill zswap entry immutable and share by different pages. That way it does not depend on the xarray pointer tagging. It can share the same code path with existing zero fill page handling. Just don't free the zero fill entry. I want to reserve the zswap xarray tagging for another purpose. Just some food for thought. Might have less complexity because it doesn't need to deal with two different kinds of pointers. Chris
