From: Barry Song <21cnbao@gmail.com>
To: Jared Hulbert <jaredeh@gmail.com>
Cc: Jan Kara <jack@suse.cz>, Chuanhua Han <hanchuanhua@oppo.com>,
Chris Li <chrisl@kernel.org>, linux-mm <linux-mm@kvack.org>,
lsf-pc@lists.linux-foundation.org, ryan.roberts@arm.com,
david@redhat.com
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony"
Date: Fri, 8 Mar 2024 13:53:30 +1300 [thread overview]
Message-ID: <CAGsJ_4yC0ayKvRNMEv4i_Z0wpgdzsZahPz5n9_YbmYU7BVAY_A@mail.gmail.com> (raw)
In-Reply-To: <CA+ZsKJ6f_-uoK24tBCQowaoo20NLpfSYXXHeuO8YM2vUL7wXYA@mail.gmail.com>
On Fri, Mar 8, 2024 at 1:15 PM Jared Hulbert <jaredeh@gmail.com> wrote:
>
> On Thu, Mar 7, 2024 at 1:17 PM Barry Song <21cnbao@gmail.com> wrote:
> >
> > I don't understand why we need this level of complexity. All we need to know
> > are the offsets during pageout. After that, the large folio is
> > destroyed, and all
> > offsets are stored in page table entries (PTEs) or xa. Swap-in doesn't depend
> > on a complex file system; it can make its own decision on how to swap-in
> > based on the values it reads from PTEs.
> >
> > Swap-in doesn't need to know whether the swapped-out folio was large or not.
>
> Right if the folio was broken down to individual pages on swap out
> then individual pages PTEs know where the data is. So I agree it's not
> necessary.
Hi Jared,
My point is that even if we fail to obtain contiguous swap offsets,
there's no need to split
large folios into smaller ones. We only need to temporarily record
discontiguous offsets for
each subpage, then proceed with pageout and try_to_unmap_one. After
this process, the
lifecycle of the large folio is complete. Once the pageout and
try_to_unmap_one operations
are done, the folio is no longer present, and the related offset
information in memory can also
be cleared.
So, I'd like to concentrate on how to record that offset information and perform
anti-fragmentation in the swap system. I don't understand why we should
get a complex fs involved here.
>
> But the folio was destroyed. We want to recreate the folio on swap in? IDK
Indeed, the primary purpose of swap-out is to release the folio (or
"release" it to the buddy system).
Before doing so, we store offsets in Page Table Entries (PTEs) or xa
in try_to_unmap_one. Swap-in
already has all the necessary information to retrieve its memory from
the swapfile.
Sorry I abused the word "destroy", I meant "release".
>
> \What if you flip the argument? The complexity of the file path exists
> already... If swap didn't exist could we justify adding the
> duplicated (albeit simpler) functionality of swap?
I don't quite get your point. Can you please give a concrete example?
Thanks
Barry
next prev parent reply other threads:[~2024-03-08 0:53 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-01 9:24 Chris Li
2024-03-01 9:53 ` Nhat Pham
2024-03-01 18:57 ` Chris Li
2024-03-04 22:58 ` Matthew Wilcox
2024-03-05 3:23 ` Chengming Zhou
2024-03-05 7:44 ` Chris Li
2024-03-05 8:15 ` Chengming Zhou
2024-03-05 18:24 ` Chris Li
2024-03-05 9:32 ` Nhat Pham
2024-03-05 9:52 ` Chengming Zhou
2024-03-05 10:55 ` Nhat Pham
2024-03-05 19:20 ` Chris Li
2024-03-05 20:56 ` Jared Hulbert
2024-03-05 21:38 ` Jared Hulbert
2024-03-05 21:58 ` Chris Li
2024-03-06 4:16 ` Jared Hulbert
2024-03-06 5:50 ` Chris Li
[not found] ` <CA+ZsKJ7JE56NS6hu4L_uyywxZO7ixgftvfKjdND9e5SOyn+72Q@mail.gmail.com>
2024-03-06 18:16 ` Chris Li
2024-03-06 22:44 ` Jared Hulbert
2024-03-07 0:46 ` Chris Li
2024-03-07 8:57 ` Jared Hulbert
2024-03-06 1:33 ` Barry Song
2024-03-04 18:43 ` Kairui Song
2024-03-04 22:03 ` Jared Hulbert
2024-03-04 22:47 ` Chris Li
2024-03-04 22:36 ` Chris Li
2024-03-06 1:15 ` Barry Song
2024-03-06 2:59 ` Chris Li
2024-03-06 6:05 ` Barry Song
2024-03-06 17:56 ` Chris Li
2024-03-06 21:29 ` Barry Song
2024-03-08 8:55 ` David Hildenbrand
2024-03-07 7:56 ` Chuanhua Han
2024-03-07 14:03 ` [Lsf-pc] " Jan Kara
2024-03-07 21:06 ` Jared Hulbert
2024-03-07 21:17 ` Barry Song
2024-03-08 0:14 ` Jared Hulbert
2024-03-08 0:53 ` Barry Song [this message]
2024-03-14 9:03 ` Jan Kara
2024-05-16 15:04 ` Zi Yan
2024-05-17 3:48 ` Chris Li
2024-03-14 8:52 ` Jan Kara
2024-03-08 2:02 ` Chuanhua Han
2024-03-14 8:26 ` Jan Kara
2024-03-14 11:19 ` Chuanhua Han
2024-05-15 23:07 ` Chris Li
2024-05-16 7:16 ` Chuanhua Han
2024-05-17 12:12 ` Karim Manaouil
2024-05-21 20:40 ` Chris Li
2024-05-28 7:08 ` Jared Hulbert
2024-05-29 3:36 ` Chris Li
2024-05-29 3:57 ` Matthew Wilcox
2024-05-29 6:50 ` Chris Li
2024-05-29 12:33 ` Matthew Wilcox
2024-05-30 22:53 ` Chris Li
2024-05-31 3:12 ` Matthew Wilcox
2024-06-01 0:43 ` Chris Li
2024-05-31 1:56 ` Yuanchu Xie
2024-05-31 16:51 ` 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=CAGsJ_4yC0ayKvRNMEv4i_Z0wpgdzsZahPz5n9_YbmYU7BVAY_A@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=hanchuanhua@oppo.com \
--cc=jack@suse.cz \
--cc=jaredeh@gmail.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=ryan.roberts@arm.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