From: Luis Chamberlain <mcgrof@kernel.org>
To: hughd@google.com, akpm@linux-foundation.org, willy@infradead.org
Cc: linux-mm@kvack.org, p.raghav@samsung.com, dave@stgolabs.net,
a.manzanares@samsung.com, yosryahmed@google.com,
mcgrof@kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC v2 0/5] tmpfs: add the option to disable swap
Date: Wed, 22 Feb 2023 18:44:07 -0800 [thread overview]
Message-ID: <20230223024412.3522465-1-mcgrof@kernel.org> (raw)
This adds noswap support to tmpfs. This follows up the first RFC [0],
you can look at that link for details of the testing done. On this
v2 I've addressed the feedback provided by Matthew Wilcox and Yosry
Ahmed. I've also made some other changes. Changes on this v2:
o Matthew suggested BUG_ON(!folio_test_locked(folio)) is not needed
on writepage() callback for shmem so just remove that.
o Based on Matthew's feedback the inode is set up early as it is not
reset in case we split the folio. So now we move all the variables
we can set up really early.
o shmem writepage() should only be issued on reclaim, so just move
the WARN_ON_ONCE(!wbc->for_reclaim) early so that the code and
expectations are easier to read. This also avoid the folio splitting
in case of that odd case.
o There are a few cases where the shmem writepage() could possibly
hit, but in the total_swap_pages we just bail out. We shouldn't be
splitting the folio then. Likewise for VM_LOCKED case. But for
a writepage() on a VM_LOCKED case is not expected so we want to
learn about it so add a WARN_ON_ONCE() on that condition.
o Based on Yosry Ahmed's feedback the patch which allows tmpfs to
disable swap now just uses mapping_set_unevictable() on inode
creation. In that case writepage() should not be called so we
augment the WARN_ON_ONCE() for writepage() for that case to ensure
that never happens.
If this all seems peachy I can move this to PATCH form next. I've tested
and indeed just using mapping_set_unevictable() suffices to disable swap
upon inode creation.
[0] https://lkml.kernel.org/r/20230207025259.2522793-1-mcgrof@kernel.org
Luis Chamberlain (5):
shmem: remove check for folio lock on writepage()
shmem: set shmem_writepage() variables early
shmem: move reclaim check early on writepages()
shmem: skip page split if we're not reclaiming
shmem: add support to ignore swap
Documentation/mm/unevictable-lru.rst | 2 +
include/linux/shmem_fs.h | 1 +
mm/shmem.c | 68 ++++++++++++++++++----------
3 files changed, 48 insertions(+), 23 deletions(-)
--
2.39.1
next reply other threads:[~2023-02-23 2:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 2:44 Luis Chamberlain [this message]
2023-02-23 2:44 ` [RFC v2 1/5] shmem: remove check for folio lock on writepage() Luis Chamberlain
2023-02-23 2:44 ` [RFC v2 2/5] shmem: set shmem_writepage() variables early Luis Chamberlain
2023-02-23 2:44 ` [RFC v2 3/5] shmem: move reclaim check early on writepages() Luis Chamberlain
2023-02-23 2:44 ` [RFC v2 4/5] shmem: skip page split if we're not reclaiming Luis Chamberlain
2023-02-23 2:44 ` [RFC v2 5/5] shmem: add support to ignore swap Luis Chamberlain
2023-02-23 12:26 ` Christian Brauner
2023-02-23 15:16 ` Christoph Hellwig
2023-02-23 16:09 ` Christian Brauner
2023-02-23 19:43 ` Luis Chamberlain
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=20230223024412.3522465-1-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--cc=a.manzanares@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=dave@stgolabs.net \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=p.raghav@samsung.com \
--cc=willy@infradead.org \
--cc=yosryahmed@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox