On Wed, 8 Nov 2017, Dan Williams wrote: > On Wed, Nov 8, 2017 at 12:26 PM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > On Wed, 8 Nov 2017, Christoph Hellwig wrote: > > > >> Can you start by explaining what you actually need the vmap for? > > > > It is possible to use lvm on persistent memory. You can create linear or > > striped logical volumes on persistent memory and these volumes still have > > the direct_access method, so they can be mapped with the function > > dax_direct_access(). > > > > If we create logical volumes on persistent memory, the method > > dax_direct_access() won't return the whole device, it will return only a > > part. When dax_direct_access() returns the whole device, my driver just > > uses it without vmap. When dax_direct_access() return only a part of the > > device, my driver calls it repeatedly to get all the parts and then > > assembles the parts into a linear address space with vmap. > > I know I proposed "call dax_direct_access() once" as a strawman for an > in-kernel driver user, but it's better to call it per access so you > can better stay in sync with base driver events like new media errors > and unplug / driver-unload. Either that, or at least have a plan how > to handle those events. Calling it on every access would be inacceptable performance overkill. How is it supposed to work anyway? - if something intends to move data on persistent memory while some driver accesse it, then we need two functions - dax_direct_access() and dax_relinquish_direct_access(). The current kernel lacks a function dax_relinquish_direct_access() that would mark a region of data as moveable, so we can't move the data anyway. BTW. what happens if we create a write bio that has its pages pointing to persistent memory and there is error when the storage controller attempts to do DMA from persistent memory? Will the storage controller react to the error in a sensible way and will the block layer report the error? Mikulas -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel