Re: [PATCH V1 1/2] libnvdimm/nsio: differentiate between probe mapping and runtime mapping

["Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>]

On 10/16/19 9:34 PM, Dan Williams wrote:
> On Tue, Oct 15, 2019 at 10:29 PM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> On 10/16/19 3:32 AM, Dan Williams wrote:
>>> On Tue, Oct 15, 2019 at 8:33 AM Aneesh Kumar K.V
>>> <aneesh.kumar@linux.ibm.com> wrote:
>>>>
>>>> nvdimm core currently maps the full namespace to an ioremap range
>>>> while probing the namespace mode. This can result in probe failures
>>>> on architectures that have limited ioremap space.
>>>
>>> Is there a #define for that limit?
>>>
>>
>> Arch specific #define. For example. ppc64 have different limits based on
>> platform and translation mode. Hash translation with 4k PAGE_SIZE limit
>> ioremap range to 8TB.
>>
>>>> nvdimm core can avoid this failure by only mapping the reserver block area to
>>>> check for pfn superblock type and map the full namespace resource only before
>>>> using the namespace. nvdimm core use ioremap range only for the raw and btt
>>>> namespace and we can limit the max namespace size for these two modes. For
>>>> both fsdax and devdax this change enables nvdimm to map namespace larger
>>>> that ioremap limit.
>>>
>>> If the direct map has more space I think it would be better to add a
>>> way to use that to map for all namespaces rather than introduce
>>> arbitrary failures based on the mode.
>>>
>>> I would buy a performance argument to avoid overmapping, but for
>>> namespace access compatibility where an alternate mapping method would
>>> succeed I think we should aim for that to be used instead. Thoughts?
>>>
>>
>> That would require to have struct page allocated for these range and
>> both raw and btt don't need a struct page backing?
>>
> 
> I was thinking a new mapping interface that just consumed direct-map
> space, but did not allocate pages.
> 

Not sure how easy that would be. We are looking at having part of 
direct-map address not managed by any zone and then possibly archs need 
to be taught to handle these ? (for example for ppc64 we "bolt" direct 
map range where as we allow taking low level hash fault for I/O remap range)

Even though you don't consider the patch as complete, considering the 
approach you outlined would require larger changes, do you think this 
patch can be accepted as a bug fix? Right now we can fail namespace
initialization during boot or ndctl enable-namespace all.

For example with ppc64 and I/O remap range limit of 8TB, we can 
individually create a 6TB namespace. We also allow to create multiple 
such namespaces. But if we try to enable them all together using ndctl 
enable-namespace all, that will fail with error

[   54.259910] vmap allocation for size x failed: use vmalloc=<size> to 
increase size

because we probe these namespaces in parallel.

-aneesh


_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org