From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA298C433DF for ; Fri, 10 Jul 2020 04:52:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 57E8E2072E for ; Fri, 10 Jul 2020 04:52:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 57E8E2072E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 974916B0006; Fri, 10 Jul 2020 00:52:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 925836B0007; Fri, 10 Jul 2020 00:52:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 838E56B0008; Fri, 10 Jul 2020 00:52:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0107.hostedemail.com [216.40.44.107]) by kanga.kvack.org (Postfix) with ESMTP id 6DDA76B0006 for ; Fri, 10 Jul 2020 00:52:57 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2AE9845A8 for ; Fri, 10 Jul 2020 04:52:57 +0000 (UTC) X-FDA: 77020946394.30.son18_45037f426ecb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id EA755180B3C94 for ; Fri, 10 Jul 2020 04:52:56 +0000 (UTC) X-HE-Tag: son18_45037f426ecb X-Filterd-Recvd-Size: 4005 Received: from out30-43.freemail.mail.aliyun.com (out30-43.freemail.mail.aliyun.com [115.124.30.43]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Fri, 10 Jul 2020 04:52:48 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07488;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0U2GOhiJ_1594356756; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U2GOhiJ_1594356756) by smtp.aliyun-inc.com(127.0.0.1); Fri, 10 Jul 2020 12:52:36 +0800 Subject: Re: a question of split_huge_page To: "Kirill A. Shutemov" , Matthew Wilcox Cc: Johannes Weiner , Linux-MM , "linux-kernel@vger.kernel.org" , Hugh Dickins References: <20200709155002.GF12769@casper.infradead.org> <20200709160750.utl46xvavceuvnom@box> From: Alex Shi Message-ID: Date: Fri, 10 Jul 2020 12:51:58 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200709160750.utl46xvavceuvnom@box> Content-Type: text/plain; charset=gbk X-Rspamd-Queue-Id: EA755180B3C94 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: =D4=DA 2020/7/10 =C9=CF=CE=E712:07, Kirill A. Shutemov =D0=B4=B5=C0: > On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: >> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: >>> Hi Kirill & Matthew, >>> >>> In the func call chain, from split_huge_page() to lru_add_page_tail()= , >>> Seems tail pages are added to lru list at line 963, but in this scena= rio >>> the head page has no lru bit and isn't set the bit later. Why we do t= his? >>> or do I miss sth? >> >> I don't understand how we get to split_huge_page() with a page that's >> not on an LRU list. Both anonymous and page cache pages should be on >> an LRU list. What am I missing?>=20 Thanks a lot for quick reply! What I am confusing is the call chain: __iommu_dma_alloc_pages() to split_huge_page(), in the func, splited page, page =3D alloc_pages_node(nid, alloc_flags, order); And if the pages were added into lru, they maybe reclaimed and lost, that would be a panic bug. But in fact, this never happened for long time= . Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmte= sts in kselftest. > Right, and it's never got removed from LRU during the split. The tail > pages have to be added to LRU because they now separate from the tail > page. >=20 According to the explaination, looks like we could remove the code path, since it's never got into. (base on my v15 patchset). Any comments? Thanks Alex diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 7c52c5228aab..c28409509ad3 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2357,17 +2357,6 @@ static void lru_add_page_tail(struct page *head, s= truct page *page_tail, if (!list) SetPageLRU(page_tail); if (likely(PageLRU(head))) list_add_tail(&page_tail->lru, &head->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. - */ - VM_BUG_ON_PAGE(1, head); - add_page_to_lru_list_tail(page_tail, lruvec, - page_lru(page_tail)); } }