On Sat, Jun 8, 2024 at 8:53 AM Takero Funaki <flintglass@xxxxxxxxx> wrote: > > This patch implements proactive shrinking of zswap pool before the max > pool size limit is reached. This also changes zswap to accept new pages > while the shrinker is running. > > To prevent zswap from rejecting new pages and incurring latency when > zswap is full, this patch queues the global shrinker by a pool usage > threshold between 100% and accept_thr_percent, instead of the max pool > size. The pool size will be controlled between 90% to 91% for the > default accept_thr_percent=90. Since the current global shrinker > continues to shrink until accept_thr_percent, we do not need to maintain > the hysteresis variable tracking the pool limit overage in > zswap_store(). > > Before this patch, zswap rejected pages while the shrinker is running > without incrementing zswap_pool_limit_hit counter. It could be a reason > why zswap writethrough new pages before writeback old pages. With this > patch, zswap accepts new pages while shrinking, and zswap increments > the counter when and only when zswap rejects pages by the max pool size. > > Now, reclaims smaller than the proactive shrinking amount finish > instantly and trigger background shrinking. Admins can check if new > pages are buffered by zswap by monitoring the pool_limit_hit counter. > > The name of sysfs tunable accept_thr_percent is unchanged as it is still > the stop condition of the shrinker. > The respective documentation is updated to describe the new behavior. > > Signed-off-by: Takero Funaki <flintglass@xxxxxxxxx> Taking a step back, could you benchmark and include relevant userspace-visible metrics to show: a) This is a problem happening in realistic-ish workloads. b) The solution shows improvements over the status quo. before we justify any extra complexity? This goes for pretty much the whole series (i.e why are we fixing this), but for this patch specifically, since we are optimizing things.
