linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


  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