Re: [PATCH v2] mm: swap: async free swap slot cache entries

[Chris Li <chrisl@kernel.org>]

On Fri, Feb 9, 2024 at 9:52 AM Tim Chen <tim.c.chen@linux.intel.com> wrote:
> > Yes, it will have the long tail latency due to batch freeing 64 entries.
> > My point is not that I don't care about heavy swap behavior.
> > My point is that the app will suffer from the swap strom anyway, it is
> > unavoidable. That will be the dominant factor shadowing the batch free
> > optimization effect.
>
> The original optimization introducing swap_slots target such heavy
> swap use cases when we have fast swap backend to allow higher sustainable
> swap throughput.  We should not ignore it.  And I am afraid your current
> patch as is will hurt that performance.  If you change the direct free
> path to free all entries, that could maintain the throughput and I'll
> be okay with that.

That is great. Thanks for the confirmation. I will send out the V3 soon.
In V3, I changed the direct free path to free all entries. I also add the
/sys/kernel/swap/swap_slot_async_free to enable the async free behavior.

>
> >
> > Or do I miss your point as you want to purpose the swap cache double
> > buffer  so it can perform better under swap storm situations?
> >
>
> I am not actually proposing doubling the buffer as that proposal have
> its own downside.

Ack

Chris