That's a long CC list for sure :)
On Wed, Jan 17, 2024 at 7:06 PM Chris Li <chrisl@xxxxxxxxxx> wrote:
>
> The RB tree shows some contribution to the swap fault
> long tail latency due to two factors:
> 1) RB tree requires re-balance from time to time.
> 2) The zswap RB tree has a tree level spin lock protecting
> the tree access.
>
> The swap cache is using xarray. The break down the swap
> cache access does not have the similar long time as zswap
> RB tree.
I think the comparison to the swap cache may not be valid as the swap
cache has many trees per swapfile, while zswap has a single tree.
>
> Moving the zswap entry to xarray enable read side
> take read RCU lock only.
Nice.
>
> The first patch adds the xarray alongside the RB tree.
> There is some debug check asserting the xarray agrees with
> the RB tree results.
>
> The second patch removes the zwap RB tree.
The breakdown looks like something that would be a development step,
but for patch submission I think it makes more sense to have a single
patch replacing the rbtree with an xarray.
>
> I expect to merge the zswap rb tree spin lock with the xarray
> lock in the follow up changes.
Shouldn't this simply be changing uses of tree->lock to use
xa_{lock/unlock}? We also need to make sure we don't try to lock the
tree when operating on the xarray if the caller is already holding the
lock, but this seems to be straightforward enough to be done as part
of this patch or this series at least.
Am I missing something?
>
> I can surely use some help in reviewing and testing.
>
> Signed-off-by: Chris Li <chrisl@xxxxxxxxxx>
> ---
> Chris Li (2):
> mm: zswap.c: add xarray tree to zswap
> mm: zswap.c: remove RB tree
>
> mm/zswap.c | 120 ++++++++++++++++++++++++++++++-------------------------------
> 1 file changed, 59 insertions(+), 61 deletions(-)
> ---
> base-commit: d7ba3d7c3bf13e2faf419cce9e9bdfc3a1a50905
> change-id: 20240104-zswap-xarray-716260e541e3
>
> Best regards,
> --
> Chris Li <chrisl@xxxxxxxxxx>
>
