[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMZfGtVQr=7pUevVbbNK9teskfGsjcoif2sfHQ-YrDx5qHNiXg@mail.gmail.com>
Date: Wed, 22 Jun 2022 15:22:35 +0800
From: Muchun Song <songmuchun@...edance.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the mm tree with the folio tree
On Wed, Jun 22, 2022 at 1:38 PM Stephen Rothwell <sfr@...b.auug.org.au> 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.
Download attachment "0001-mm-lru-use-lruvec-lock-to-serialize-memcg-changes.patch" of type "application/octet-stream" (7510 bytes)
Powered by blists - more mailing lists