[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67eb23cbcd0b7_11987294fd@dwillia2-xfh.jf.intel.com.notmuch>
Date: Mon, 31 Mar 2025 16:22:51 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Nhat Pham <nphamcs@...il.com>, Dan Williams <dan.j.williams@...el.com>
CC: <linux-mm@...ck.org>, <akpm@...ux-foundation.org>, <hannes@...xchg.org>,
<yosry.ahmed@...ux.dev>, <chengming.zhou@...ux.dev>, <sj@...nel.org>,
<kernel-team@...a.com>, <linux-kernel@...r.kernel.org>, <gourry@...rry.net>,
<willy@...radead.org>, <ying.huang@...ux.alibaba.com>,
<jonathan.cameron@...wei.com>, <linux-cxl@...r.kernel.org>,
<minchan@...nel.org>, <senozhatsky@...omium.org>
Subject: Re: [RFC PATCH 1/2] zsmalloc: let callers select NUMA node to store
the compressed objects
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.
...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".
Powered by blists - more mailing lists