Re: [PATCH] vmalloc: introduce vmap_pfn for persistent memory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 9, 2017 at 8:37 AM, Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote:
>
>
> 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.

We take a global reference on the hosting device while pages are
registered, see the percpu_ref usage in kernel/memremap.c, and we hold
the dax_read_lock() over calls to dax_direct_access() to temporarily
hold the device alive for the duration of the call.

> 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?

While pages are pinned for DMA the devm_memremap_pages() mapping is
pinned. Otherwise, an error reading persistent memory is identical to
an error reading DRAM.

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux