From: Yosry Ahmed <yosryahmed@google.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Chris Li <chrisl@kernel.org>,
Daniel Gomez <da.gomez@samsung.com>,
Pankaj Raghav <p.raghav@samsung.com>,
Hugh Dickins <hughd@google.com>,
David Howells <dhowells@redhat.com>,
Nhat Pham <nphamcs@gmail.com>,
lsf-pc@lists.linux-foundation.org, netfs@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [LSF/MM/BPF TOPIC] Large folios, swap and fscache
Date: Thu, 22 Feb 2024 19:16:01 +0000 [thread overview]
Message-ID: <ZdedcU9NRJ8-ws33@google.com> (raw)
In-Reply-To: <ZdeaQMDjsSmIRXHB@bombadil.infradead.org>
On Thu, Feb 22, 2024 at 11:02:24AM -0800, Luis Chamberlain wrote:
> On Fri, Feb 02, 2024 at 02:29:40PM +0000, Matthew Wilcox wrote:
> > So my modest proposal is that we completely rearchitect how we handle
> > swap. Instead of putting swp entries in the page tables (and in shmem's
> > case in the page cache), we turn swap into an (object, offset) lookup
> > (just like a filesystem). That means that each anon_vma becomes its
> > own swap object and each shmem inode becomes its own swap object.
> > The swap system can then borrow techniques from whichever filesystem
> > it likes to do (object, offset, length) -> n x (device, block) mappings.
>
> What happened to Yosry or Chris's last year's pony [0]? In order to try
For me, I unfortunately got occuppied with other projects and don't have
the bandwidth to work on it for now :/
I don't want to put anyone on the spot, but I think Nhat may have been
thinking about pursuing a version of this at some point.
> to take a stab at this we started with adding large folios to tmpfs,
> which Daniel Gomez has taken on, as its a simple filesystem and with
> large folios can enable us to easily test large folio swap support too.
> Daniel first tried fixing lseek issue with huge pages [1] and on top of
> that he has patches (a new RFC not posted yet) which do add large folios
> support to tmpfs. Hugh has noted the lskeek changes are incorrect and
> suggested instead a fix for the failed tests in fstests. If we get
> agreement on Hugh's approach then we have a step forward with tmpfs and
> later we hope this will make it easier to test swap changes.
>
> Its probably then a good time to ask, do we have a list of tests for
> swap to ensure we don't break things if we add large folio support?
> We can at least start with a good baseline of tests for that.
>
> [0] https://lwn.net/Articles/932077/
> [1] https://lkml.kernel.org/r/20240209142901.126894-1-da.gomez@samsung.com
>
> Luis
next prev parent reply other threads:[~2024-02-22 19:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 9:09 [LSF/MM/BPF TOPIC] Large folios, swap and fscache David Howells
2024-02-02 14:29 ` Matthew Wilcox
2024-02-02 15:57 ` David Howells
2024-02-02 19:22 ` Matthew Wilcox
2024-02-22 19:02 ` Luis Chamberlain
2024-02-22 19:16 ` Yosry Ahmed [this message]
2024-02-22 22:26 ` Chris Li
2024-02-29 19:31 ` Chris Li
2024-02-03 5:13 ` Gao Xiang
2024-02-04 23:45 ` Dave Chinner
2024-02-22 22:45 ` Chris Li
2024-02-23 3:00 ` Andreas Dilger
2024-02-23 3:46 ` Chris Li
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=ZdedcU9NRJ8-ws33@google.com \
--to=yosryahmed@google.com \
--cc=chrisl@kernel.org \
--cc=da.gomez@samsung.com \
--cc=dhowells@redhat.com \
--cc=hughd@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mcgrof@kernel.org \
--cc=netfs@lists.linux.dev \
--cc=nphamcs@gmail.com \
--cc=p.raghav@samsung.com \
--cc=willy@infradead.org \
/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.