Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 31 Aug 2020 20:59:24 -0700 (PDT)
From:   Hugh Dickins <hughd@google.com>
To:     Alex Shi <alex.shi@linux.alibaba.com>
cc:     Hugh Dickins <hughd@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@suse.com>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        Shakeel Butt <shakeelb@google.com>,
        Matthew Wilcox <willy@infradead.org>, Qian Cai <cai@lca.pw>,
        Chris Wilson <chris@chris-wilson.co.uk>,
        Kuo-Hsin Yang <vovoy@chromium.org>,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 4/5] mm: fix check_move_unevictable_pages() on THP
In-Reply-To: <5875bdbe-c1af-737b-9ec2-4b48b3c2465f@linux.alibaba.com>
Message-ID: <alpine.LSU.2.11.2008312040530.1019@eggly.anvils>
References: <alpine.LSU.2.11.2008301343270.5954@eggly.anvils> <alpine.LSU.2.11.2008301405000.5954@eggly.anvils> <5875bdbe-c1af-737b-9ec2-4b48b3c2465f@linux.alibaba.com>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1560420255-1598932776=:1019"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1560420255-1598932776=:1019
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 1 Sep 2020, Alex Shi wrote:
> =E5=9C=A8 2020/8/31 =E4=B8=8A=E5=8D=885:08, Hugh Dickins =E5=86=99=E9=81=
=93:
> > --- 5.9-rc2/mm/vmscan.c=092020-08-16 17:32:50.721507348 -0700
> > +++ linux/mm/vmscan.c=092020-08-28 17:47:10.595580876 -0700
> > @@ -4260,8 +4260,14 @@ void check_move_unevictable_pages(struct
> >  =09for (i =3D 0; i < pvec->nr; i++) {
> >  =09=09struct page *page =3D pvec->pages[i];
> >  =09=09struct pglist_data *pagepgdat =3D page_pgdat(page);
> > +=09=09int nr_pages;
> > +
> > +=09=09if (PageTransTail(page))
> > +=09=09=09continue;
> > +
> > +=09=09nr_pages =3D thp_nr_pages(page);
> > +=09=09pgscanned +=3D nr_pages;
> > =20
> > -=09=09pgscanned++;
> >  =09=09if (pagepgdat !=3D pgdat) {
> >  =09=09=09if (pgdat)
> >  =09=09=09=09spin_unlock_irq(&pgdat->lru_lock);
> > @@ -4280,7 +4286,7 @@ void check_move_unevictable_pages(struct
> >  =09=09=09ClearPageUnevictable(page);
> >  =09=09=09del_page_from_lru_list(page, lruvec, LRU_UNEVICTABLE);
> >  =09=09=09add_page_to_lru_list(page, lruvec, lru);
>=20
> So, we might randomly del or add a thp tail page into lru?
> It's interesting to know here. :)

No, it wasn't that interesting, I'd have been more concerned if it was
like that.  Amusing idea though: because the act of adding a thp tail
to lru would clear the very bit that says it's a tail.

=09=09if (!PageLRU(page) || !PageUnevictable(page))
=09=09=09continue;

Let's see: PageLRU and PageUnevictable are both of the PF_HEAD type,
so permitted on tails, but always redirecting to head: so typically
PageLRU(page) would be true, because head on lru; but PageUnevictable(page)
would be false on tail, because head has already been moved to an evictable
lru by this same function.  So it safely went the "continue" way, but
without incrementing pgrescued.

Hugh

>=20
> Thanks
> Alex
>=20
> > -=09=09=09pgrescued++;
> > +=09=09=09pgrescued +=3D nr_pages;
> >  =09=09}
> >  =09}
> > =20
--0-1560420255-1598932776=:1019--