On Tue, Nov 19, 2019 at 7:19 PM Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com> wrote: > > On 11/19/19 11:28 PM, Dan Williams wrote: > > On Mon, Nov 18, 2019 at 1:52 AM Aneesh Kumar K.V > > <aneesh.ku...@linux.ibm.com> wrote: > >> > >> Dan Williams <dan.j.willi...@intel.com> writes: > >> > >>> On Sat, Nov 16, 2019 at 4:15 AM Aneesh Kumar K.V > >>> <aneesh.ku...@linux.ibm.com> wrote: > >>>> > >> > >> .... > >> > >> > >>>> > >>>> Considering the direct-map map size is not going to be user selectable, > >>>> do you agree that we can skip the above step 0 configuration you > >>>> suggested. > >>>> > >>>> The changes proposed in the patch series essentially does the rest. > >>>> > >>>> 1) It validate the size against the arch specific limit during > >>>> namespace creation. (part of step 1) > >>> > >>> This validation is a surprise failure to ndctl. > >>> > >>>> 2) It also disable initializing a region if it find the size not > >>>> correctly aligned as per the platform requirement. > >>> > >>> There needs to be a way for the user to discover the correct alignment > >>> that the kernel will accept. > >>> > >>>> 3) Direct map mapping size is different from supported_alignment for a > >>>> namespace. The supported alignment controls what possible PAGE SIZE user > >>>> want the > >>>> namespace to be mapped to user space. > >>> > >>> No, the namespace alignment is different than the page mapping size. > >>> The alignment is only interpreted as a mapping size at the device-dax > >>> level, otherwise at the raw namespace level it's just an arbitrary > >>> alignment. > >>> > >>>> With the above do you think the current patch series is good? > >>> > >>> I don't think we've quite converged on a solution. > >> > >> How about we make it a property of seed device. ie, > >> we add `supported_size_align` RO attribute to the seed device. ndctl can > >> use this to validate the size value. So this now becomes step0 > >> > >> sys/bus/nd/devices/region0> cat btt0.0/supported_size_align > >> 16777216 > >> /sys/bus/nd/devices/region0> cat pfn0.0/supported_size_align > >> 16777216 > >> /sys/bus/nd/devices/region0> cat dax0.0/supported_size_align > >> 16777216 > > > > Why on those devices and not namespace0.0? > > sure. > > > > >> We follow that up with validating the size value written to size > >> attribute(step 1). > >> > >> While initializing the namespaces already present in a region we again > >> validate the size and if not properly aligned we mark the region > >> disabled. > > > > The region might have a mix of namespaces, some aligned and some not, > > only the misaligned namespaces should fail to enable. The region > > should otherwise enable successfully. > > > > One misaligned namespace would mean, we get other namespace resource > start addr wrongly aligned. If we allow regions to be enabled with > namespace with wrong size, user would find further namespace creation in > that regions failing due to wrongly aligned resource start. IMHO that is > a confusing user experience. >
Why would one wrongly aligned namespace prevent other namespaces from being aligned? There's no requirement that consecutive namespaces are allocated contiguously. Also consider a namespace that starts misaligned, but ends aligned. That subsequent namespace can be enabled without issue.
