On 10/16/19 9:34 PM, Dan Williams wrote:
On Tue, Oct 15, 2019 at 10:29 PM Aneesh Kumar K.V
<[email protected]> wrote:
On 10/16/19 3:32 AM, Dan Williams wrote:
On Tue, Oct 15, 2019 at 8:33 AM Aneesh Kumar K.V
<[email protected]> 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 -- [email protected]
To unsubscribe send an email to [email protected]
