Re: [RFC PATCH 1/2] zsmalloc: let callers select NUMA node to store the compressed objects

[Nhat Pham]

On Mon, Mar 31, 2025 at 4:23 PM Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>
> Nhat Pham wrote:
> [..]
> > That still leaves zram though. zram is more complicated than zswap -
> > it has multiple allocation paths, so I don't want to touch it quite
> > yet (and preferably a zram maintainer/developer should do it). :) Or
> > if zram maintainers are happy with NUMA_NO_NODE, then we can
> > completely get rid of the pointer arguments etc.
>
> At a minimum make the argument a "const int *" so it does not look like
> the value can be changed by the leaf functions.

That's a good idea! I'll incorporate it into the next version.

>
> ...but I would challenge zram folks to ack/nak that change rather than
> maintain old behavior based purely on momentum. I.e. add to the commit
> message an "exclude zswap from this policy for $explicit_reason"
> statement rather than the current $implicit_guess that the old behavior
> is there for "reasons".

Yeah I'll take a look at the zram code. There's no conceptual reason
why zram can not or should not adopt the same behavior, from my POV -
it's just a bit more complicated than zswap, and as such would require
more hacking. So I'm leaning towards making the minimal change
required to support zswap first, and letting the zram
maintainers/developers work it out on the zram side :) We'll see!