On Wed, Mar 13, 2024 at 12:31 AM Chris Li <chrisl@xxxxxxxxxx> wrote: > > Very deep RB tree requires rebalance at times. That > contributes to the zswap fault latencies. Xarray does not > need to perform tree rebalance. Replacing RB tree to xarray > can have some small performance gain. > > One small difference is that xarray insert might fail with > ENOMEM, while RB tree insert does not allocate additional > memory. > > The zswap_entry size will reduce a bit due to removing the > RB node, which has two pointers and a color field. Xarray > store the pointer in the xarray tree rather than the > zswap_entry. Every entry has one pointer from the xarray > tree. Overall, switching to xarray should save some memory, > if the swap entries are densely packed. > > Notice the zswap_rb_search and zswap_rb_insert always > followed by zswap_rb_erase. Use xa_erase and xa_store > directly. That saves one tree lookup as well. > > Remove zswap_invalidate_entry due to no need to call > zswap_rb_erase any more. Use zswap_free_entry instead. > > The "struct zswap_tree" has been replaced by "struct xarray". > The tree spin lock has transferred to the xarray lock. > > Run the kernel build testing 10 times for each version, averages: > (memory.max=2GB, zswap shrinker and writeback enabled, > one 50GB swapfile, 24 HT core, 32 jobs) > > mm-9a0181a3710eb xarray v5 > user 3532.385 3535.658 > sys 536.231 530.083 > real 200.431 200.176 > > --- > > > Reviewed-by: Barry Song <baohua@xxxxxxxxxx> > Reviewed-by: Chengming Zhou <chengming.zhou@xxxxxxxxx> > Acked-by: Yosry Ahmed <yosryahmed@xxxxxxxxxx> > Signed-off-by: Chris Li <chrisl@xxxxxxxxxx> Apologies for the delayed review :) LGTM FWIW. Looks like you're sending a fixlet to address Johannes' comments, but I assume it won't change too much, so feel free to include: Reviewed-by: Nhat Pham <nphamcs@xxxxxxxxx>
