On Sat, Dec 23, 2023 at 7:01 PM David Rientjes <rientjes@xxxxxxxxxx> wrote: > > On Sat, 23 Dec 2023, Chris Li wrote: > > > > How do you quantify the impact of the delayed swap_entry_free()? > > > > > > Since the free and memcg uncharge are now delayed, is there not the > > > possibility that we stay under memory pressure for longer? (Assuming at > > > least some users are swapping because of memory pressure.) > > > > > > I would assume that since the free and uncharge itself is delayed that in > > > the pathological case we'd actually be swapping *more* until the async > > > worker can run. > > > > Thanks for raising this interesting question. > > > > First of all, the swap_entry_free() does not impact "memory.current". > > It reduces "memory.swap.current". Technically it is the swap pressure > > not memory pressure that suffers the extra delay. > > > > Secondly, we are talking about delaying up to 64 swap entries for a > > few microseconds. > > What guarantees that the async freeing happens within a few microseconds? Linux kernel typically doesn't provide RT scheduling guarantees. You can change microseconds to milliseconds, my following reasoning still holds. > > > Where the swap slot cache itself delays the freeing > > of the entries for an arbitrary amount of time. It is not freed until > > the cache is full of 64 entries. This delay can be seconds or even > > minutes. Adding a few microseconds of extra delay to existing seconds > > delay really makes no difference from the swap pressure point of view. Let me rephrase it. The swap slots cache itself has arbiturely delayed on freeing the swap slots, the slot is not free until 64 entries are reached. Adding a few milliseconds to the current swap slot freeing delay does not significantly change current behavior from swap pressure point of view. Chris
