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=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,URIBL_BLOCKED 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 DE053C433E4 for ; Mon, 22 Jun 2020 13:12:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C33FF20760 for ; Mon, 22 Jun 2020 13:10:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C33FF20760 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 2C1C96B0002; Mon, 22 Jun 2020 09:10:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 227616B0003; Mon, 22 Jun 2020 09:10:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C7E66B0005; Mon, 22 Jun 2020 09:10:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0162.hostedemail.com [216.40.44.162]) by kanga.kvack.org (Postfix) with ESMTP id D96C06B0002 for ; Mon, 22 Jun 2020 09:10:13 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8ED83DE09 for ; Mon, 22 Jun 2020 13:10:13 +0000 (UTC) X-FDA: 76956881106.05.tramp07_3e1669c26e33 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id BADD818006857 for ; Mon, 22 Jun 2020 13:10:12 +0000 (UTC) X-HE-Tag: tramp07_3e1669c26e33 X-Filterd-Recvd-Size: 6498 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 22 Jun 2020 13:10:09 +0000 (UTC) X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R131e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01355;MF=richard.weiyang@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0U0OSU9i_1592831403; Received: from localhost(mailfrom:richard.weiyang@linux.alibaba.com fp:SMTPD_---0U0OSU9i_1592831403) by smtp.aliyun-inc.com(127.0.0.1); Mon, 22 Jun 2020 21:10:04 +0800 Date: Mon, 22 Jun 2020 21:10:03 +0800 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , stable@vger.kernel.org, Andrew Morton , Johannes Weiner , Minchan Kim , Huang Ying , Wei Yang , Mel Gorman Subject: Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps Message-ID: <20200622131003.GA98415@L-31X9LVDL-1304.local> Reply-To: Wei Yang References: <20200619125923.22602-1-david@redhat.com> <20200619125923.22602-2-david@redhat.com> <20200622082635.GA93552@L-31X9LVDL-1304.local> <2185539f-b210-5d3f-5da2-a497b354eebb@redhat.com> <20200622092221.GA96699@L-31X9LVDL-1304.local> <34f36733-805e-cc61-38da-2ee578ae096c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34f36733-805e-cc61-38da-2ee578ae096c@redhat.com> X-Rspamd-Queue-Id: BADD818006857 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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: On Mon, Jun 22, 2020 at 11:51:34AM +0200, David Hildenbrand wrote: >On 22.06.20 11:22, Wei Yang wrote: >> On Mon, Jun 22, 2020 at 10:43:11AM +0200, David Hildenbrand wrote: >>> On 22.06.20 10:26, Wei Yang wrote: >>>> On Fri, Jun 19, 2020 at 02:59:20PM +0200, David Hildenbrand wrote: >>>>> Especially with memory hotplug, we can have offline sections (with a >>>>> garbage memmap) and overlapping zones. We have to make sure to only >>>>> touch initialized memmaps (online sections managed by the buddy) and that >>>>> the zone matches, to not move pages between zones. >>>>> >>>>> To test if this can actually happen, I added a simple >>>>> BUG_ON(page_zone(page_i) != page_zone(page_j)); >>>>> right before the swap. When hotplugging a 256M DIMM to a 4G x86-64 VM and >>>>> onlining the first memory block "online_movable" and the second memory >>>>> block "online_kernel", it will trigger the BUG, as both zones (NORMAL >>>>> and MOVABLE) overlap. >>>>> >>>>> This might result in all kinds of weird situations (e.g., double >>>>> allocations, list corruptions, unmovable allocations ending up in the >>>>> movable zone). >>>>> >>>>> Fixes: e900a918b098 ("mm: shuffle initial free memory to improve memory-side-cache utilization") >>>>> Acked-by: Michal Hocko >>>>> Cc: stable@vger.kernel.org # v5.2+ >>>>> Cc: Andrew Morton >>>>> Cc: Johannes Weiner >>>>> Cc: Michal Hocko >>>>> Cc: Minchan Kim >>>>> Cc: Huang Ying >>>>> Cc: Wei Yang >>>>> Cc: Mel Gorman >>>>> Signed-off-by: David Hildenbrand >>>>> --- >>>>> mm/shuffle.c | 18 +++++++++--------- >>>>> 1 file changed, 9 insertions(+), 9 deletions(-) >>>>> >>>>> diff --git a/mm/shuffle.c b/mm/shuffle.c >>>>> index 44406d9977c77..dd13ab851b3ee 100644 >>>>> --- a/mm/shuffle.c >>>>> +++ b/mm/shuffle.c >>>>> @@ -58,25 +58,25 @@ module_param_call(shuffle, shuffle_store, shuffle_show, &shuffle_param, 0400); >>>>> * For two pages to be swapped in the shuffle, they must be free (on a >>>>> * 'free_area' lru), have the same order, and have the same migratetype. >>>>> */ >>>>> -static struct page * __meminit shuffle_valid_page(unsigned long pfn, int order) >>>>> +static struct page * __meminit shuffle_valid_page(struct zone *zone, >>>>> + unsigned long pfn, int order) >>>>> { >>>>> - struct page *page; >>>>> + struct page *page = pfn_to_online_page(pfn); >>>> >>>> Hi, David and Dan, >>>> >>>> One thing I want to confirm here is we won't have partially online section, >>>> right? We can add a sub-section to system, but we won't manage it by buddy. >>> >>> Hi, >>> >>> there is still a BUG with sub-section hot-add (devmem), which broke >>> pfn_to_online_page() in corner cases (especially, see the description in >>> include/linux/mmzone.h). We can have a boot-memory section partially >>> populated and marked online. Then, we can hot-add devmem, marking the >>> remaining pfns valid - and as the section is maked online, also as online. >> >> Oh, yes, I see this description. >> >> This means we could have section marked as online, but with a sub-section even >> not added. >> >> While the good news is even the sub-section is not added, but its memmap is >> populated for an early section. So the page returned from pfn_to_online_page() >> is a valid one. >> >> But what would happen, if the sub-section is removed after added? Would >> section_deactivate() release related memmap to this "struct page"? > >If devmem is removed, the memmap will be freed and the sub-sections are >marked as non-present. So this works as expected. > Sorry, I may not catch your point. If my understanding is correct, the above behavior happens in function section_deactivate(). Let me draw my understanding of function section_deactivate(): section_deactivate(pfn, nr_pages) clear_subsection_map(pfn, nr_pages) depopulate_section_memmap(pfn, nr_pages) Since we just remove a sub-section, I skipped some un-related codes. These two functions would: * clear bitmap in ms->usage->subsection_map * free memmap for the sub-section While since the section is not empty, ms->section_mem_map is not set no null. Per my understanding, the section present state is set in ms->section_mem_map with SECTION_MARKED_PRESENT. It looks we don't clear it when just remote a sub-section. Do I miss something? >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me