[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKEwX=OtpnH+i4FtZ66HPoe7zRRtEBuMbHQ9+LW4k5yLK+yHNw@mail.gmail.com>
Date: Wed, 25 Sep 2024 07:28:59 -0700
From: Nhat Pham <nphamcs@...il.com>
To: Barry Song <baohua@...nel.org>
Cc: "Huang, Ying" <ying.huang@...el.com>, Yosry Ahmed <yosryahmed@...gle.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
hannes@...xchg.org, hughd@...gle.com, shakeel.butt@...ux.dev,
ryan.roberts@....com, chrisl@...nel.org, david@...hat.com, kasong@...cent.com,
willy@...radead.org, viro@...iv.linux.org.uk, chengming.zhou@...ux.dev,
linux-mm@...ck.org, kernel-team@...a.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] remove SWAP_MAP_SHMEM
On Wed, Sep 25, 2024 at 7:21 AM Nhat Pham <nphamcs@...il.com> wrote:
>
> On Wed, Sep 25, 2024 at 12:33 AM Barry Song <baohua@...nel.org> wrote:
> How does this look? My concern is that there is not really a use for
> the fallback logic. Basically dead code.
>
> I can keep it in if you guys have a use for it soon, but otherwise I
> lean towards just adding a WARN etc. there, or return -ENOMEM, and
> WARN at shmem's callsite (because it cannot get -ENOMEM).
Oh and another point - I plan to rewrite this swap entity lifetime
logic in the new abstraction layer. The swap continuation part will go
away with it - I don't quite like the way we're currently doing
things. So this added complexity might be unnecessary.
Powered by blists - more mailing lists