Re: [PATCH v4 mm-new 1/2] mm/swap: do not choose swap device according to numa node

[Chris Li <chrisl@kernel.org>]

On Wed, Oct 15, 2025 at 1:09 AM Barry Song <21cnbao@gmail.com> wrote:
> >
> > Optane was not even supported in Skylake. Commit a2468cc9bfdf has
> > nothing to do with Optane. The Op]tane talk in a2468cc9bfdf is just a
> > red herring. I fail to see why reverting a2468cc9bfdf needs to mention
> > Optane is obsolete.
>
> Thanks for the clarification. The Optane discussion turned out to be a goof :-)
>
> Just for the record, this paper [1] also mentions that accessing remote SSDs
> can significantly decrease performance. However, it is rare to find any NUMA

Ack. I am not saying NUMA is aware SSD does not matter. I am sure it
does. The question is does the benefit in real world usage cases
justify the extra complexity.

> machine using SSDs directly as swap files without a RAM compression frontend,
> so I don’t think the performance penalty of remote access would be a problem
> when choosing a direct swapfile.

The per NUMA aware SSD swap setup is so hard to come by, very few
users are actually benefiting from it in real life. You need to have
each NUMA node a SSD attached to that node. Also each SSD on the node
needs to set up the swap partition, preferably the same size. If you
have only one SSD setup the swap partition, it does not matter if it
is local or remote, that is the only SSD swap can write to anyway.

Both Android and data center usage I am aware of do not satisfy this
per NUMA node swapfile requirement. If anyone has a counterexample, I
would like to hear about it. My conguesture is that this setup is so
rare, it does not justify the complexity it adds to the swap core.
Especially considering it has conflict with the swap.tiers down the
road.

Agree that nowadays the zswap or zram is the more common swap usage
case by far, the SSD swap is just an overflow secondary swap. The
local vs remote SSD speed difference there matters much less.

Chris