On Thu, Nov 16, 2023 at 12:30 PM Chris Li <chriscli@xxxxxxxxxx> wrote: > > On Thu, Nov 16, 2023 at 12:19 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > Not bypassing the swap slot cache, just make the callbacks to > > invalidate the zswap entry, do memg uncharging, etc when the slot is > > no longer used and is entering the swap slot cache (i.e. when > > free_swap_slot() is called), instead of when draining the swap slot > > cache (i.e. when swap_range_free() is called). For all parts of MM > > outside of swap, the swap entry is freed when free_swap_slot() is > > called. We don't free it immediately because of caching, but this > > should be transparent to other parts of MM (e.g. zswap, memcg, etc). > > That will cancel the batching effect on the swap slot free, making the > common case for swapping faults take longer to complete, righ? > If I recall correctly, the uncharge is the expensive part of the swap > slot free operation. > I just want to figure out what we are trading off against. This is not > one side wins all situations. Interesting. Maybe we can just move the zswap_invalidate() call to save memory early, and leave the memcg uncharge call to be batched? IIUC we already do some version of this internally at Google. > > > Chris
