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.
