[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9fa2cf92-c4a0-02ca-1f02-7ef71952de18@linux.alibaba.com>
Date: Tue, 7 Jul 2020 20:00:11 +0800
From: Alex Shi <alex.shi@...ux.alibaba.com>
To: akpm@...ux-foundation.org, mgorman@...hsingularity.net,
tj@...nel.org, hughd@...gle.com, khlebnikov@...dex-team.ru,
daniel.m.jordan@...cle.com, yang.shi@...ux.alibaba.com,
willy@...radead.org, hannes@...xchg.org, lkp@...el.com,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
cgroups@...r.kernel.org, shakeelb@...gle.com,
iamjoonsoo.kim@....com, richard.weiyang@...il.com,
"Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCH v15 05/21] mm/thp: move lru_add_page_tail func to
huge_memory.c
在 2020/7/7 下午7:46, Alex Shi 写道:
>
> +static void lru_add_page_tail(struct page *page, struct page *page_tail,
> + struct lruvec *lruvec, struct list_head *list)
> +{
> + VM_BUG_ON_PAGE(!PageHead(page), page);
> + VM_BUG_ON_PAGE(PageCompound(page_tail), page);
> + VM_BUG_ON_PAGE(PageLRU(page_tail), page);
> + lockdep_assert_held(&lruvec_pgdat(lruvec)->lru_lock);
> +
> + if (!list)
> + SetPageLRU(page_tail);
> +
> + if (likely(PageLRU(page)))
> + list_add_tail(&page_tail->lru, &page->lru);
> + else if (list) {
> + /* page reclaim is reclaiming a huge page */
> + get_page(page_tail);
> + list_add_tail(&page_tail->lru, list);
> + } else {
> + /*
> + * Head page has not yet been counted, as an hpage,
> + * so we must account for each subpage individually.
> + *
> + * Put page_tail on the list at the correct position
> + * so they all end up in order.
> + */
> + add_page_to_lru_list_tail(page_tail, lruvec,
> + page_lru(page_tail));
I missed some points for this function, since in the call chain:
split_huge_page() to lru_add_page_tail, the head page's lru won't be
set when !PageLRU(head). But the other page_tail are add to lru list here
Is it ok for this situation?
Thanks!
Alex
> + }
> +}
Powered by blists - more mailing lists