[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200624011118.GA9422@L-31X9LVDL-1304.local>
Date: Wed, 24 Jun 2020 09:11:18 +0800
From: Wei Yang <richard.weiyang@...ux.alibaba.com>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Wei Yang <richard.weiyang@...ux.alibaba.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Oscar Salvador <osalvador@...e.de>,
Linux MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH] mm/spase: never partially remove memmap for early section
On Tue, Jun 23, 2020 at 05:21:06PM -0700, Dan Williams wrote:
>On Tue, Jun 23, 2020 at 2:43 AM Wei Yang
><richard.weiyang@...ux.alibaba.com> wrote:
>>
>> For early sections, we assumes its memmap will never be partially
>> removed. But current behavior breaks this.
>
>Where do we assume that?
>
>The primary use case for this was mapping pmem that collides with
>System-RAM in the same 128MB section. That collision will certainly be
>depopulated on-demand depending on the state of the pmem device. So,
>I'm not understanding the problem or the benefit of this change.
Hi, Dan
There is a discussion in the thread you just replied:
mm/shuffle: don't move pages between zones and don't read garbage memmaps
Besides this, the comment in section_activate() says:
* The early init code does not consider partially populated
* initial sections, it simply assumes that memory will never be
* referenced. If we hot-add memory into such a section then we
* do not need to populate the memmap and can simply reuse what
* is already there.
Per my understanding, if we hot-add then hot-remove the sub-section, we may
not have a valid memmep for this part sub-section? Because we depopulate it at
hot-remove while we don't populate it when hot-add.
Is my understanding correct?
--
Wei Yang
Help you, Help me
Powered by blists - more mailing lists