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?

-aneesh
_______________________________________________
Linux-nvdimm mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to