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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2017/1/18 1:15, Dan Williams wrote:
> On Tue, Jan 17, 2017 at 5:58 AM, zhong jiang <zhongjiang@xxxxxxxxxx> wrote:
>> On 2017/1/17 18:25, Michal Hocko wrote:
>>> On Mon 16-01-17 21:38:05, zhongjiang wrote:
>>>> From: zhong jiang <zhongjiang@xxxxxxxxxx>
>>>>
>>>> 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.
 The rules ensure that (reserve + free) need to less than one section size.
 if it is so, or we add WARNON to explicitly the limits.


 Thanks
 zhongjiang
> .
>
 

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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]