On Wed, Dec 6, 2023 at 7:25 PM Chengming Zhou <zhouchengming@xxxxxxxxxxxxx> wrote: > > 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! Let's split the rbtree breakdown into a separate series. This series has irrelevant (and very nice) cleanups and optimizations, let's get them separately and defer the rbtree breakdown part until we get data about the xarray implementation. Perhaps the tree breakdown is not needed as much with an xarray, or at the very least the implementation would look different on top of an xarray.
