Re: [PATCH v4 0/4] mm: ZSWAP swap-out of mTHP folios

[Nhat Pham <nphamcs@gmail.com>]

On Mon, Aug 19, 2024 at 11:01 PM Sridhar, Kanchana P
<kanchana.p.sridhar@intel.com> wrote:
>
> Hi Ying,
>
> I confirmed that in the case of usemem, all calls to [1] occur from the code path in [3].
> However, my takeaway from this is that the more reclaim that results in zswap_store(),
> for e.g., from mTHP folios, there is higher likelihood of overage recorded per-process in
> current->memcg_nr_pages_over_high, which could potentially be causing each
> process to reclaim memory, even if it is possible that the swapout from a few of
> the 70 processes could have brought the parent cgroup under the limit.

Yeah IIUC, the memory increase from zswap store happens
immediately/synchronously (swap_writepage() -> zswap_store() ->
obj_cgroup_charge_zswap()), before the memory saving kicks in. This is
a non-issue for swap - the memory saving doesn't happen right away,
but it also doesn't increase memory usage (well, as you pointed out,
obj_cgroup_charge_zswap() doesn't even happen).

And yes, this is compounded a) if you're in a high concurrency regime,
where all tasks in the same cgroup, under memory pressure, all go into
reclaim. and b) for larger folios, where we compress multiple pages
before the saving happens. I wonder how bad the effect is tho - could
you quantify the reclamation amount that happens per zswap store
somehow with tracing magic?

Also, I wonder if there is a "charge delta" mechanism, where we
directly uncharge by (page size - zswap object size), to avoid the
temporary double charging... Sort of like what folio migration is
doing now v.s what it used to do. Seems complicated - not even sure if
it's possible TBH.

>
> Please do let me know if you have any other questions. Appreciate your feedback
> and comments.
>
> Thanks,
> Kanchana