From: Zhaoyang Huang <huangzhaoyang@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: David Hildenbrand <david@redhat.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Andrew Morton <akpm@linux-foundation.org>,
Yu Zhao <yuzhao@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-mm@kvack.org, steve.kang@unisoc.com
Subject: Re: [RFC PATCH 1/1] mm: Skip folio with private data during isolation
Date: Tue, 27 Aug 2024 10:53:03 +0800 [thread overview]
Message-ID: <CAGWkznEBHpXExYx0Gvg782B_otf-4g97okRhBJg4TBCSeZ7F2A@mail.gmail.com> (raw)
In-Reply-To: <Zs0-pkXmO2WY37Mp@casper.infradead.org>
On Tue, Aug 27, 2024 at 10:49 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Aug 27, 2024 at 10:45:11AM +0800, Zhaoyang Huang wrote:
> > On Mon, Aug 26, 2024 at 9:01 PM David Hildenbrand <david@redhat.com> wrote:
> > > On 26.08.24 13:10, Zhaoyang Huang wrote:
> > > > On Mon, Aug 26, 2024 at 6:36 PM David Hildenbrand <david@redhat.com> wrote:
> > > >> An earlier filemap_release_folio() would have failed if the private data
> > > >> (buffers) cannot get freed, and we went into the activate_locked path.
> > > >>
> > > >> if (folio_needs_release(folio)) {
> > > >> if (!filemap_release_folio(folio, sc->gfp_mask)
> > > >> goto activate_locked;
> > > >> ...
>
> > No, this is actually a migration failure issue[1] related to cma_alloc
> > where the bh keeps busy as the journal's transaction can't be
> > launched[2][3][4][5][6]. I am just inspired by this issue to check if
> > there is anything to do in reclaiming. By counting from a ramdump,
> > there are 300MB "lru, private" pages found in a 6GB RAM system which
> > could lower the reclaiming efficiency if the same scenario as above
> > happens.
>
> As David said, if we encounter a filesystem folio with private data,
> we ask the filesystem to strip the private data off. Usually this
> succeeds, because most folios aren't part of the journal for very long.
Got it, thanks for clarifying.
prev parent reply other threads:[~2024-08-27 2:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 8:50 zhaoyang.huang
2024-08-26 10:36 ` David Hildenbrand
2024-08-26 11:10 ` Zhaoyang Huang
2024-08-26 13:01 ` David Hildenbrand
2024-08-27 2:45 ` Zhaoyang Huang
2024-08-27 2:49 ` Matthew Wilcox
2024-08-27 2:53 ` Zhaoyang Huang [this message]
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=CAGWkznEBHpXExYx0Gvg782B_otf-4g97okRhBJg4TBCSeZ7F2A@mail.gmail.com \
--to=huangzhaoyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=steve.kang@unisoc.com \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
--cc=zhaoyang.huang@unisoc.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