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. _______________________________________________ Linux-nvdimm mailing list -- [email protected] To unsubscribe send an email to [email protected]
