linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Chen Ridong <chenridong@huaweicloud.com>
Cc: akpm@linux-foundation.org, mhocko@suse.com, hannes@cmpxchg.org,
	yosryahmed@google.com, yuzhao@google.com, david@redhat.com,
	ryan.roberts@arm.com, baohua@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, chenridong@huawei.com,
	wangweiyang2@huawei.com, xieym_ict@hotmail.com
Subject: Re: [RFC PATCH v2 1/1] mm/vmscan: move the written-back folios to the tail of LRU after shrinking
Date: Mon, 18 Nov 2024 04:03:26 +0000	[thread overview]
Message-ID: <Zzq8jsAQNYgDKSGN@casper.infradead.org> (raw)
In-Reply-To: <20241116091658.1983491-2-chenridong@huaweicloud.com>

On Sat, Nov 16, 2024 at 09:16:58AM +0000, Chen Ridong wrote:
> 2. In shrink_page_list function, if folioN is THP(2M), it may be splited
>    and added to swap cache folio by folio. After adding to swap cache,
>    it will submit io to writeback folio to swap, which is asynchronous.
>    When shrink_page_list is finished, the isolated folios list will be
>    moved back to the head of inactive lru. The inactive lru may just look
>    like this, with 512 filioes have been move to the head of inactive lru.

I was hoping that we'd be able to stop splitting the folio when adding
to the swap cache.  Ideally. we'd add the whole 2MB and write it back
as a single unit.

This is going to become much more important with memdescs.  We'd have to
allocate 512 struct folios to do this, which would be about 10 4kB pages,
and if we're trying to swap out memory, we're probably low on memory.

So I don't like this solution you have at all because it doesn't help us
get to the solution we're going to need in about a year's time.


  parent reply	other threads:[~2024-11-18  4:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-16  9:16 [RFC PATCH v2 0/1] " Chen Ridong
2024-11-16  9:16 ` [RFC PATCH v2 1/1] " Chen Ridong
2024-11-17  3:26   ` Barry Song
2024-11-18  2:18     ` Chen Ridong
2024-11-18  4:03   ` Matthew Wilcox [this message]
2024-11-18  4:14     ` Barry Song
2024-11-18  4:21       ` Matthew Wilcox
2024-11-25  1:19         ` chenridong
2024-11-28 23:08           ` Barry Song
2024-11-29  2:25             ` chenridong
2024-11-29  3:07               ` Barry Song
2024-11-27  0:08         ` Chris Li
2024-11-18  9:41       ` chenridong
2024-11-18  9:55         ` Barry Song
2024-11-27  0:17           ` 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=Zzq8jsAQNYgDKSGN@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=chenridong@huawei.com \
    --cc=chenridong@huaweicloud.com \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=ryan.roberts@arm.com \
    --cc=wangweiyang2@huawei.com \
    --cc=xieym_ict@hotmail.com \
    --cc=yosryahmed@google.com \
    --cc=yuzhao@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