Re: [RFC PATCH 1/2] mm: always call rmap_walk() on locked folios

[Barry Song <21cnbao@gmail.com>]

[...]
> > > > >
> > > > > IIUC, shink_active_list() doesn't behave any differently whether there
> > > > > is contention or not, except when it's an executable file folio. So I
> > > > > doubt such data would be any useful. Please correct me if I'm wrong.
> > > >
> > > > Since we skipped clearing the PTE young bit in folio_referenced_one, a
> > > > cold page might be misidentified as hot during shrink_inactive_list().
> > > > My understanding is that as long as the percentage is small, this
> > > > shouldn't be a concern.
> > > I see. That makes a lot more sense why folio_referenced() is called on
> > > all folios in shrink_active_list(). I missed that young bit clearing
> > > before.
> > >
> > > Any suggestions on a good testcase to gather this data?
> >
> > I would run monkey for a few hours with some debug counters, e.g. how
> > many folios pass through shrink_active_list(), how many get contended
> > and moved to the inactive list without clearing the young bit. If the
> > percentage is small, we can just ignore this disordered LRU behavior.
> >
> Thanks for the suggestion, Barry.
>
> Monkey test wasn't successful in creating sufficient mem pressure. So,
> I used an app cycle test. It took over 1 hour to complete it on an
> arm64 Android device with memory limited to 6GB.
>
> During the test shrink_active_list() got called over 140k times. Out
> of that, over 29k invocations had at least one non-KSM anon folio.
> None of the folio_referenced() calls on these folios ended up with
> contention i.e. folio_trylock() failing.
>
> So, as thought, this patch doesn't seem to have any negative effect on
> shrink_active_list().

Cool, thanks! It seems to meet expectations, given that a folio is
a very small granularity. I also raised another discussion [1],
which, if it works out, should provide one more reason why we
need your patches.


[1] https://lore.kernel.org/linux-mm/CAGsJ_4x=YsQR=nNcHA-q=0vg0b7ok=81C_qQqKmoJ+BZ+HVduQ@mail.gmail.com/

Thanks
Barry