On 2023/12/7 08:43, Chris Li wrote: > Hi Nhat and Yosry, > > On Wed, Dec 6, 2023 at 12:42 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: >> >> On Wed, Dec 6, 2023 at 9:24 AM Nhat Pham <nphamcs@xxxxxxxxx> wrote: >>> >>> + Chris Li >>> >>> Chris, I vaguely remember from our last conversation that you have >>> some concurrent efforts to use xarray here right? > > Yes, I do have the zswap xarray for older versions of the kernel. The > recent mm-unstable tree has a lot of zswap related updates. Give me 2 > days to refresh and post it. The zswap invalid entry and the reference > count change is causing a good portion of the code to be updated. That > is the price to pay keeping out of tree patches. My fault is not > getting to it sooner. > >> >> If I recall correctly, the xarray already reduces the lock contention >> as lookups are lockless, but Chris knows more here. As you mentioned > > Yes. To be exact, xarray can use spin lock (same as current RB tree) > or take RCU read lock on the lookup path (depending on how you call > the xarray API). Not completely lockless but the RCU read lock should > have less lock contention than normal spinlock. +Matthew > Great! Lockless lookup in zswap_load() should reduce spinlock contention. And multiple trees (multiple xarrays) can further reduce the contention on the concurrent zswap_store() side. So it's complementary IMHO. >> in a different email, it would be nice to get some data so that we can >> compare different solutions. > > Yes, it is certainly welcome to see more data points. If I recall > correctly, the zswap xarray array makes the lookup similar to the swap > cache lookup. It has a noticeable difference in the long tail end. > Right, I post some data from yesterday in another reply. Will test again and update the data since Nhat's zswap shrinker fix patch has been merged into mm-unstable today. Thanks!
