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=-6.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_1 autolearn=no 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 1FD78C433E4 for ; Tue, 28 Jul 2020 11:20:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4AA52070A for ; Tue, 28 Jul 2020 11:20:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4AA52070A 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 6F0C18D000F; Tue, 28 Jul 2020 07:20:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 69EA38D0005; Tue, 28 Jul 2020 07:20:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 518038D000F; Tue, 28 Jul 2020 07:20:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 381508D0005 for ; Tue, 28 Jul 2020 07:20:11 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id EF2A83623 for ; Tue, 28 Jul 2020 11:20:10 +0000 (UTC) X-FDA: 77087240580.01.rat43_150961826f69 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id B3EF4100483E9 for ; Tue, 28 Jul 2020 11:20:10 +0000 (UTC) X-HE-Tag: rat43_150961826f69 X-Filterd-Recvd-Size: 6961 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jul 2020 11:20:08 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01422;MF=alex.shi@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0U43yIOJ_1595935203; Received: from IT-FVFX43SYHV2H.local(mailfrom:alex.shi@linux.alibaba.com fp:SMTPD_---0U43yIOJ_1595935203) by smtp.aliyun-inc.com(127.0.0.1); Tue, 28 Jul 2020 19:20:03 +0800 Subject: Re: [PATCH v17 17/21] mm/lru: replace pgdat lru_lock with lruvec lock To: Alexander Duyck Cc: Andrew Morton , Mel Gorman , Tejun Heo , Hugh Dickins , Konstantin Khlebnikov , Daniel Jordan , Yang Shi , Matthew Wilcox , Johannes Weiner , kbuild test robot , linux-mm , LKML , cgroups@vger.kernel.org, Shakeel Butt , Joonsoo Kim , Wei Yang , "Kirill A. Shutemov" , Rong Chen , Michal Hocko , Vladimir Davydov References: <1595681998-19193-1-git-send-email-alex.shi@linux.alibaba.com> <1595681998-19193-18-git-send-email-alex.shi@linux.alibaba.com> From: Alex Shi Message-ID: Date: Tue, 28 Jul 2020 19:19:52 +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: Content-Type: text/plain; charset=utf-8 X-Rspamd-Queue-Id: B3EF4100483E9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: =E5=9C=A8 2020/7/28 =E4=B8=8A=E5=8D=887:34, Alexander Duyck =E5=86=99=E9=81= =93: >> @@ -1876,6 +1876,12 @@ static unsigned noinline_for_stack move_pages_t= o_lru(struct lruvec *lruvec, >> * list_add(&pa= ge->lru,) >> * list_add(&page->lru,) //corrupt >> */ >> + new_lruvec =3D mem_cgroup_page_lruvec(page, page_pgdat= (page)); >> + if (new_lruvec !=3D lruvec) { >> + if (lruvec) >> + spin_unlock_irq(&lruvec->lru_lock); >> + lruvec =3D lock_page_lruvec_irq(page); >> + } >> SetPageLRU(page); >> >> if (unlikely(put_page_testzero(page))) { > I was going through the code of the entire patch set and I noticed > these changes in move_pages_to_lru. What is the reason for adding the > new_lruvec logic? My understanding is that we are moving the pages to > the lruvec provided are we not?If so why do we need to add code to get > a new lruvec? The code itself seems to stand out from the rest of the > patch as it is introducing new code instead of replacing existing > locking code, and it doesn't match up with the description of what > this function is supposed to do since it changes the lruvec. this new_lruvec is the replacement of removed line, as following code: >> - lruvec =3D mem_cgroup_page_lruvec(page, pgdat); This recheck is for the page move the root memcg, otherwise it cause the = bug: [ 2081.240795] BUG: kernel NULL pointer dereference, address: 00000000000= 00000 [ 2081.248125] #PF: supervisor read access in kernel mode [ 2081.253627] #PF: error_code(0x0000) - not-present page [ 2081.259124] PGD 8000000044cb0067 P4D 8000000044cb0067 PUD 95c9067 PMD = 0 [ 2081.266193] Oops: 0000 [#1] PREEMPT SMP PTI [ 2081.270740] CPU: 5 PID: 131 Comm: kswapd0 Kdump: loaded Tainted: G = W 5.8.0-rc6-00025-gc708f8a0db47 #45 [ 2081.281960] Hardware name: Alibaba X-Dragon CN 01/20G4B, BIOS 1ALSP016= 05/21/2018 [ 2081.290054] RIP: 0010:do_raw_spin_trylock+0x5/0x40 [ 2081.295209] Code: 76 82 48 89 df e8 bb fe ff ff eb 8c 89 c6 48 89 df e= 8 4f dd ff ff 66 90 eb 8b 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00= <8b> 07 85 c0 75 28 ba 01 00 00 00 f0 0f b1 17 75 1d 65 8b 05 03 6a [ 2081.314832] RSP: 0018:ffffc900002ebac8 EFLAGS: 00010082 [ 2081.320410] RAX: 0000000000000000 RBX: 0000000000000018 RCX: 000000000= 0000000 [ 2081.327907] RDX: ffff888035833480 RSI: 0000000000000000 RDI: 000000000= 0000000 [ 2081.335407] RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000= 0000001 [ 2081.342907] R10: 0000000000000000 R11: 0000000000000000 R12: 000000000= 0000001 [ 2081.350405] R13: dead000000000100 R14: 0000000000000000 R15: ffffc9000= 02ebbb0 [ 2081.357908] FS: 0000000000000000(0000) GS:ffff88807a200000(0000) knlG= S:0000000000000000 [ 2081.366619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2081.372717] CR2: 0000000000000000 CR3: 0000000031228005 CR4: 000000000= 03606e0 [ 2081.380215] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 000000000= 0000000 [ 2081.387713] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 000000000= 0000400 [ 2081.395198] Call Trace: [ 2081.398008] _raw_spin_lock_irq+0x47/0x80 [ 2081.402387] ? move_pages_to_lru+0x566/0xb80 [ 2081.407028] move_pages_to_lru+0x566/0xb80 [ 2081.411495] shrink_active_list+0x355/0xa70 [ 2081.416054] shrink_lruvec+0x4f7/0x810 [ 2081.420176] ? mem_cgroup_iter+0xb6/0x410 [ 2081.424558] shrink_node+0x1cc/0x8d0 [ 2081.428510] balance_pgdat+0x3cf/0x760 [ 2081.432634] kswapd+0x232/0x660 [ 2081.436147] ? finish_wait+0x80/0x80 [ 2081.440093] ? balance_pgdat+0x760/0x760 [ 2081.444382] kthread+0x17e/0x1b0 [ 2081.447975] ? kthread_park+0xc0/0xc0 [ 2081.452005] ret_from_fork+0x22/0x30 Thanks! Alex >=20 >> @@ -1883,16 +1889,15 @@ static unsigned noinline_for_stack move_pages_= to_lru(struct lruvec *lruvec, >> __ClearPageActive(page); >> >> if (unlikely(PageCompound(page))) { >> - spin_unlock_irq(&pgdat->lru_lock); >> + spin_unlock_irq(&lruvec->lru_lock); >> destroy_compound_page(page); >> - spin_lock_irq(&pgdat->lru_lock); >> + spin_lock_irq(&lruvec->lru_lock); >> } else >> list_add(&page->lru, &pages_to_free); >> >> continue; >> } >> >> - lruvec =3D mem_cgroup_page_lruvec(page, pgdat); >> lru =3D page_lru(page); >> nr_pages =3D hpage_nr_pages(page);