On Wed, Jun 22, 2022 at 1:38 PM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>
> Hi all,
>
> Today's linux-next merge of the mm tree got a conflict in:
>
> mm/vmscan.c
>
> between commit:
>
> 15077be8badc ("vmscan: Add check_move_unevictable_folios()")
Sorry for the conflicts, I didn't see this change in the mm-unstable branch
yesterday. Based on this commit, I have reworked the following commit
(see attachment, mainly changes are about check_move_unevictable_folios()).
Andrew can pick it up if he wants to replace the original patch with
the new one.
>
> from the folio tree and commits:
>
> cca700a8e695 ("mm: lru: use lruvec lock to serialize memcg changes")
>
> from the mm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc mm/vmscan.c
> index 04f8671caad9,60335f974803..000000000000
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@@ -4823,18 -4856,22 +4873,17 @@@ void check_move_unevictable_folios(stru
> int pgrescued = 0;
> int i;
>
> - for (i = 0; i < pvec->nr; i++) {
> - struct page *page = pvec->pages[i];
> - struct folio *folio = page_folio(page);
> - int nr_pages;
> -
> - if (PageTransTail(page))
> - continue;
> + for (i = 0; i < fbatch->nr; i++) {
> + struct folio *folio = fbatch->folios[i];
> + int nr_pages = folio_nr_pages(folio);
>
> - nr_pages = folio_nr_pages(folio);
> pgscanned += nr_pages;
>
> - /* block memcg migration while the folio moves between lrus */
> - if (!folio_test_clear_lru(folio))
> + lruvec = folio_lruvec_relock_irq(folio, lruvec);
> + if (!folio_test_lru(folio) || !folio_test_unevictable(folio))
> continue;
>
> - lruvec = folio_lruvec_relock_irq(folio, lruvec);
> - if (folio_evictable(folio) && folio_test_unevictable(folio)) {
> + if (folio_evictable(folio)) {
> lruvec_del_folio(lruvec, folio);
> folio_clear_unevictable(folio);
> lruvec_add_folio(lruvec, folio);
The above fix is no problem. But I have something to confirm since I
do not see the next lines of the code. There is a "folio_set_lru(folio);"
in the end of this if branch, it should be removed as well.
Thanks.
Attachment:
0001-mm-lru-use-lruvec-lock-to-serialize-memcg-changes.patch
Description: Binary data
