On Tue, 1 Sep 2020, Alex Shi wrote:
> 在 2020/8/31 上午5:08, Hugh Dickins 写道:
> > --- 5.9-rc2/mm/vmscan.c 2020-08-16 17:32:50.721507348 -0700
> > +++ linux/mm/vmscan.c 2020-08-28 17:47:10.595580876 -0700
> > @@ -4260,8 +4260,14 @@ void check_move_unevictable_pages(struct
> > for (i = 0; i < pvec->nr; i++) {
> > struct page *page = pvec->pages[i];
> > struct pglist_data *pagepgdat = page_pgdat(page);
> > + int nr_pages;
> > +
> > + if (PageTransTail(page))
> > + continue;
> > +
> > + nr_pages = thp_nr_pages(page);
> > + pgscanned += nr_pages;
> >
> > - pgscanned++;
> > if (pagepgdat != pgdat) {
> > if (pgdat)
> > spin_unlock_irq(&pgdat->lru_lock);
> > @@ -4280,7 +4286,7 @@ void check_move_unevictable_pages(struct
> > ClearPageUnevictable(page);
> > del_page_from_lru_list(page, lruvec, LRU_UNEVICTABLE);
> > add_page_to_lru_list(page, lruvec, lru);
>
> 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.
if (!PageLRU(page) || !PageUnevictable(page))
continue;
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
>
> Thanks
> Alex
>
> > - pgrescued++;
> > + pgrescued += nr_pages;
> > }
> > }
> >
