Messages in this thread | | | From | Logan Gunthorpe <> | Date | Fri, 2 Mar 2018 15:24:36 -0700 | Subject | Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory |
| |
On 02/03/18 02:44 PM, Benjamin Herrenschmidt wrote: > Allright, so, I think I have a plan to fix this, but it will take a > little bit of time. > > Basically the idea is to have firmware pass to Linux a region that's > known to not have anything in it that it can use for the vmalloc space > rather than have linux arbitrarily cut the address space in half. > > I'm pretty sure I can always find large enough "holes" in the physical > address space that are outside of both RAM/OpenCAPI/Nvlink and > PCIe/MMIO space. If anything, unused chip IDs. But I don't want Linux > to have to know about the intimate HW details so I'll pass it from FW. > > It will take some time to adjust Linux and get updated FW around > though. > > Once that's done, I'll be able to have the linear mapping go through > the entire 52-bit space (minus that hole). Of course the hole need to > be large enough to hold a vmemmap for a 52-bit space, so that's about > 4TB. So I probably need a hole that's at least 8TB. > > As for the mapping attributes, it should be easy for my linear mapping > code to ensure anything that isn't actual RAM is mapped NC.
Very cool. I'm glad to hear you found a way to fix this.
Thanks,
Logan
| |