> > On Wed 09-05-18 14:04:21, Huaisheng HS1 Ye wrote: > > > From: owner-linux-mm@xxxxxxxxx [mailto:owner-linux-mm@xxxxxxxxx] On Behalf Of > Michal Hocko > > > > > > On Wed 09-05-18 04:22:10, Huaisheng HS1 Ye wrote: > [...] > > > > Current mm treats all memory regions equally, it divides zones just by size, > like > > > 16M for DMA, 4G for DMA32, and others above for Normal. > > > > The spanned range of all zones couldn't be overlapped. > > > > > > No, this is not correct. Zones can overlap. > > > > Hi Michal, > > > > Thanks for pointing it out. > > But function zone_sizes_init decides > > arch_zone_lowest/highest_possible_pfn's size by max_low_pfn, then > > free_area_init_nodes/node are responsible for calculating the spanned > > size of zones from memblock memory regions. So, ZONE_DMA and > > ZONE_DMA32 and ZONE_NORMAL have separate address scope. How can they > > be overlapped with each other? > > Sorry, I could have been a bit more specific. DMA, DMA32 and Normal > zones are exclusive. They are mapped to a specific physical range of > memory so they cannot overlap. I was referring to a general property > that zones might interleave. Especially zone Normal, Movable and Device. Exactly, here ZONE_NVM is a real physical range same as ZONE_DMA, ZONE_DMA32 and ZONE_Normal. So, it couldn't overlap with other zones. Just like you mentioned, ZONE_MOVABLE is virtual zone, which comes ZONE_Normal. The way of virtual zone is another implementation compared with current patch for ZONE_NVM. It has advantages but also disadvantages, which need to be clarified and discussed. Sincerely, Huaisheng Ye