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