From: Matthew Wilcox <willy@infradead.org>
To: Gao Xiang <hsiangkao@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Carlos Maiolino <cmaiolino@redhat.com>,
Eric Sandeen <esandeen@redhat.com>,
"Huang, Ying" <ying.huang@intel.com>,
Yang Shi <yang.shi@linux.alibaba.com>,
Rafael Aquini <aquini@redhat.com>,
Dave Chinner <david@fromorbit.com>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH v2] mm, THP, swap: fix allocating cluster for swapfile by mistake
Date: Thu, 20 Aug 2020 12:34:48 +0100 [thread overview]
Message-ID: <20200820113448.GM17456@casper.infradead.org> (raw)
In-Reply-To: <20200820045323.7809-1-hsiangkao@redhat.com>
On Thu, Aug 20, 2020 at 12:53:23PM +0800, Gao Xiang wrote:
> SWP_FS is used to make swap_{read,write}page() go through
> the filesystem, and it's only used for swap files over
> NFS. So, !SWP_FS means non NFS for now, it could be either
> file backed or device backed. Something similar goes with
> legacy SWP_FILE.
>
> So in order to achieve the goal of the original patch,
> SWP_BLKDEV should be used instead.
This is clearly confusing. I think we need to rename SWP_FS to SWP_FS_OPS.
More generally, the swap code seems insane. I appreciate that it's an
inherited design from over twenty-five years ago, and nobody wants to
touch it, but it's crazy that it cares about how the filesystem has
mapped file blocks to disk blocks. I understand that the filesystem
has to know not to allocate memory in order to free memory, but this
is already something filesystems have to understand. It's also useful
for filesystems to know that this is data which has no meaning after a
power cycle (so it doesn't need to be journalled or snapshotted or ...),
but again, that's useful functionality which we could stand to present
to userspace anyway.
I suppose the tricky thing about it is that working on the swap code is
not as sexy as working on a filesystem, and doing the swap code right
is essentially writing a filesystem, so everybody who's capable already
has something better to do.
Anyway, Gao, please can you submit a follow-on patch to rename SWP_FS?
next prev parent reply other threads:[~2020-08-20 11:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-20 4:53 [PATCH v2] mm, THP, swap: fix allocating cluster for swapfile by mistake Gao Xiang
2020-08-20 5:05 ` Huang, Ying
2020-08-20 5:05 ` Huang, Ying
2020-08-20 11:34 ` Matthew Wilcox [this message]
2020-08-20 11:49 ` Gao Xiang
2020-08-20 15:31 ` Yang Shi
2020-08-20 15:31 ` Yang Shi
2020-08-20 15:51 ` Rafael Aquini
2020-08-20 23:34 ` Dave Chinner
2020-08-21 0:21 ` Gao Xiang
2020-08-21 1:03 ` Dave Chinner
2020-08-21 2:59 ` Huang, Ying
2020-08-21 2:59 ` Huang, Ying
2020-08-21 0:28 ` Rafael Aquini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200820113448.GM17456@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=aquini@redhat.com \
--cc=cmaiolino@redhat.com \
--cc=david@fromorbit.com \
--cc=esandeen@redhat.com \
--cc=hsiangkao@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stable@vger.kernel.org \
--cc=yang.shi@linux.alibaba.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.