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

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

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.

--
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>