On Fri, 2023-12-08 at 09:20 +0000, Zhijian Li (Fujitsu) wrote: > > > On 08/12/2023 03:25, Verma, Vishal L wrote: > > On Thu, 2023-12-07 at 08:29 +0000, Zhijian Li (Fujitsu) wrote: > > > Hi Vishal, > > > > > > > > > On 07/12/2023 12:36, Vishal Verma wrote: > > > > + > > > > +What: /sys/bus/dax/devices/daxX.Y/memmap_on_memory > > > > +Date: October, 2023 > > > > +KernelVersion: v6.8 > > > > +Contact: nvd...@lists.linux.dev > > > > +Description: > > > > + (RW) Control the memmap_on_memory setting if the dax > > > > device > > > > + were to be hotplugged as system memory. This determines > > > > whether > > > > + the 'altmap' for the hotplugged memory will be placed > > > > on the > > > > + device being hotplugged (memmap_on+memory=1) or if it > > > > will be > > > > > > s/memmap_on+memory=1/memmap_on_memory=1 > > > > Thanks, will fix. > > > > > > > > > I have a question here > > > > > > What relationship about memmap_on_memory and 'ndctl-create-namespace > > > -M' option which > > > specifies where is the vmemmap backed memory. > > > I'm confused that memmap_on_memory=1 and '-M dev' are the same for > > > nvdimm devdax mode ? > > > > > The main difference is that memory that comes from non-nvdimm sources, > > such as hmem, or cxl, doesn't have a chance to set up the altmaps as > > pmem can with '-M dev'. For these, memmap_on_memory does this as part > > of the memory hotplug. > > Thanks for your explanation. > (I wrongly thought nvdimm.kmem was also controlled by '-M dev' before) > > feel free add: > Tested-by: Li Zhijian <lizhij...@fujitsu.com>
Thank you Zhijian!