On Fri, Feb 9, 2024 at 9:52 AM Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> 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
