Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3448327ybt; Tue, 23 Jun 2020 02:32:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyb21Zd7QI1sIDOTLEURxhDAqT4zP06zHJpC3EwdTgfYE/smVYMzWyY9GCwylIeURaOB60/ X-Received: by 2002:a17:906:9387:: with SMTP id l7mr9518091ejx.274.1592904760737; Tue, 23 Jun 2020 02:32:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592904760; cv=none; d=google.com; s=arc-20160816; b=kqz00m4W+3orkWpQt/FQlBbDRe5a4G1LwNZaQe34u5VF5pdwSGDFG4DZHHfITg3mSC L1f+c6DIeFnk4ygVhggssP4M8RdwGAzwd33Zq1NawcRrWMV9FvS8VdmtmDq6wjDY35Cd i30y+CEtWcnxPeyGn2vUtXuzIHD1lDr4AH+QG8GiXIUMDOGJJfFIQojl+8BMVh/AjwWK ioTLaY1LTmq7LQomVadIjzxE/J2pBdZjdgmckT/L+2+If0qcOryk38lYKsmcCU1ItZ4f Zcw0UK74h/1us/2hPZO/bFFmhqsNAlr2tjJ4hmCB+KtdRiG6YiD8b5QNXkYiKlJHupMe I9ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:reply-to:message-id:subject:cc:to:from:date; bh=P/3r4sE002W+eJcsfrvVGXYRJ+J7oXK6zpw9241/2BM=; b=U9ubUCZoX/EYt6qvBR0R0TA+fs9PGSZh2GOCFo8hZ3ZydTjHl6us6xbprLGJrqHH7M t/R2dJYjE1UaK/4ViLNF3dwJcU9LzjIaEL4p9yZ4rhqBMjd425S51JevACOW7AAWfS3z 5SV5qDBLinhSleQ045Z2gso5cFWesULu8lC4x0qNheqPe5Og6a2cCcm1ebIoacadKhp8 ilP7FMlfXfgahZnzG2Pb4fuQml2QBXcnQmGuQYrgsaEfVbFvpaEPVUQF/NcQsg33r+Iz kvds8VUPxZKAfzQPLTcNnyO8bERxTaTERnnWDXQRnLZnHT3pjKlWjgBLxqFFHsD9dXj8 DRAw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a9si10874062ejk.553.2020.06.23.02.32.18; Tue, 23 Jun 2020 02:32:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732122AbgFWJaZ (ORCPT + 99 others); Tue, 23 Jun 2020 05:30:25 -0400 Received: from out30-132.freemail.mail.aliyun.com ([115.124.30.132]:46772 "EHLO out30-132.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731968AbgFWJaY (ORCPT ); Tue, 23 Jun 2020 05:30:24 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=richard.weiyang@linux.alibaba.com;NM=1;PH=DS;RN=13;SR=0;TI=SMTPD_---0U0V8lOr_1592904618; Received: from localhost(mailfrom:richard.weiyang@linux.alibaba.com fp:SMTPD_---0U0V8lOr_1592904618) by smtp.aliyun-inc.com(127.0.0.1); Tue, 23 Jun 2020 17:30:18 +0800 Date: Tue, 23 Jun 2020 17:30:18 +0800 From: Wei Yang To: David Hildenbrand Cc: Wei Yang , 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 , Mel Gorman , Dan Williams Subject: Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps Message-ID: <20200623093018.GA6069@L-31X9LVDL-1304.local> Reply-To: Wei Yang References: <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> <20200622131003.GA98415@L-31X9LVDL-1304.local> <0f4edc1f-1ce2-95b4-5866-5c4888db7c65@redhat.com> <20200622215520.wa6gjr2hplurwy57@master> <4b7ee49c-9bee-a905-3497-e3addd8896b8@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 09:55:43AM +0200, David Hildenbrand wrote: >On 23.06.20 09:39, David Hildenbrand wrote: >>> Hmm.. I thought this is the behavior for early section, while it looks current >>> code doesn't work like this: >>> >>> if (section_is_early && memmap) >>> free_map_bootmem(memmap); >>> else >>> depopulate_section_memmap(pfn, nr_pages, altmap); >>> >>> section_is_early is always "true" for early section, while memmap is not-NULL >>> only when sub-section map is empty. >>> >>> If my understanding is correct, when we remove a sub-section in early section, >>> the code would call depopulate_section_memmap(), which in turn free related >>> memmap. By removing the memmap, the return value from pfn_to_online_page() is >>> not a valid one. >> >> I think you're right, and pfn_valid() would also return true, as it is >> an early section. This looks broken. >> >>> >>> Maybe we want to write the code like this: >>> >>> if (section_is_early) >>> if (memmap) >>> free_map_bootmem(memmap); >>> else >>> depopulate_section_memmap(pfn, nr_pages, altmap); >>> >> >> I guess that should be the way to go >> >> @Dan, I think what Wei proposes here is correct, right? Or how does it >> work in the VMEMMAP case with early sections? >> > >Especially, if you would re-hot-add, section_activate() would assume >there is a memmap, it must not be removed. > You are right here. I didn't notice it. >@Wei, can you send a patch? > Sure, let me prepare for it. >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me