On Tue, Aug 27, 2024 at 10:49 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > > On 26.08.24 13:10, Zhaoyang Huang wrote:
> > > > On Mon, Aug 26, 2024 at 6:36 PM David Hildenbrand <david@xxxxxxxxxx> 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.
