Messages in this thread | | | From | Huaisheng HS1 Ye <> | Subject | RE: [External] [RFC PATCH v1 3/6] mm, zone_type: create ZONE_NVM and fill into GFP_ZONE_TABLE | Date | Thu, 10 May 2018 03:53:34 +0000 |
| |
> > On Wed 09-05-18 14:04:21, Huaisheng HS1 Ye wrote: > > > From: owner-linux-mm@kvack.org [mailto:owner-linux-mm@kvack.org] 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
| |