On Fri, Oct 20, 2017 at 09:16:21PM -0700, Dan Williams wrote: > > For example, I think it's entirely sensible to support ->direct_access > > for RAID-0. Dell are looking at various different options for having > > one pmemX device per DIMM and using RAID to lash them together. > > ->direct_access makes no sense for RAID-5 or RAID-1, but RAID-0 makes > > sense to me. > > > > Last time we tried to take sleeping out, there were grumblings from people > > with network block devices who thought they'd want to bring pages in > > across the network. I'm a bit less sympathetic to this because I don't > > know anyone actively working on it, but the RAID-0 case is something I > > think we should care about. > > True, good point. In fact we already support device-mapper striping > with ->direct_access(). I'd still like to go ahead with the sleeping > removal. When those folks come back and add network direct_access they > can do the hard work of figuring out cases where we need to call > direct_access in atomic contexts. It would be great to move DAX striping out of DM so that we don't need to keep fake block devices around just for that. In fact if Dell is so interested in it it would be great if they get a strip/concact table into ACPI so that the bios and OS can agree on it in a standardized way, and we can just implement it in the nvdimm layer. I agree that there is no reason at all to support sleeping in ->direct_access - it makes life painful for no gain at all. If you network access remote memory you will need local memory to support mmap, so we might as well use the page cache instead of reinventing it. (saying that with my remote pmem over NFS hat on). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
