Re: [PATCH] mm: respect pre-allocated storage mapping for memmap

[Dan Williams <dan.j.williams@intel.com>]

On Wed, Jan 18, 2017 at 5:27 AM, zhong jiang <zhongjiang@huawei.com> wrote:
> On 2017/1/18 1:15, Dan Williams wrote:
>> On Tue, Jan 17, 2017 at 5:58 AM, zhong jiang <zhongjiang@huawei.com> wrote:
>>> On 2017/1/17 18:25, Michal Hocko wrote:
>>>> On Mon 16-01-17 21:38:05, zhongjiang wrote:
>>>>> From: zhong jiang <zhongjiang@huawei.com>
>>>>>
>>>>> At present, we skip the reservation storage by the driver for
>>>>> the zone_dvice. but the free pages set aside for the memmap is
>>>>> ignored. And since the free pages is only used as the memmap,
>>>>> so we can also skip the corresponding pages.
>>>> I have really hard time to understand what this patch does and why it
>>>> matters.  Could you please rephrase the changelog to state, the problem,
>>>> how it affects users and what is the fix please?
>>>>
>>>   Hi, Michal
>>>
>>>   The patch maybe incorrect if free pages for memmap mapping is accouted for zone_device.
>>>   I am just a little confusing about the implement.  it maybe simple and  stupid.
>> The patch is incorrect, the struct page initialization starts
>> immediately after altmap->reserve.
>>
>>>   first pfn for dev_mappage come from vmem_altmap_offset, and free pages reserved for
>>>   memmap mapping need to be accounted. I do not know the meaning.
>>>
>>>   Another issue is in sparse_remove_one_section.  A section belongs to  zone_device is not
>>>   always need to consider the  map_offset. is it right ?  From pfn_first to end , that section
>>>   should no need to consider the map_offet.
>> No that's not right. devm_memremap_pages() will specify the full
>> physical address range that was initially hotplugged. At removal time
>> the first page of the memmap starts at pfn_to_page(phys_start_pfn +
>> map_offset).
>>
>> However, I always need to remind myself of these rules every time I
>> read the code, so the documentation needs improvement.
>>
>> .
>>
> Addtional, if we just offline some of sectiones of dev_mappage. That will have question.
> Therefore,  we must offline the whole dev_mappages page that belongs to zone_device.
>
> is it right?  please
>

We never online ZONE_DEVICE memory so consequently it can never be
offlined. The only way to access the pages is via get_user_pages() of
a DAX mapping.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>