Re: [Lsf-pc] [LSF/MM TOPIC] Persistent memory: pmem as storage device vs pmem as memory

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

 



On Wed, Feb 3, 2016 at 5:19 AM, Jan Kara <jack@xxxxxxx> wrote:
> On Tue 02-02-16 17:10:18, Dan Williams wrote:
>> The current state of persistent memory enabling in Linux is that a
>> physical memory range discovered by a device driver is exposed to the
>> system as a block device.  That block device has the added property of
>> being capable of DAX which, at its core, allows converting
>> storage-device-sectors allocated to a file into pages that can be
>> mmap()ed, DMAed, etc...
>>
>> In that quick two sentence summary the impacted kernel sub-systems
>> span mm, fs, block, and a device-driver.  As a result when a
>> persistent memory design question arises there are mm, fs, block, and
>> device-driver specific implications to consider.  Are there existing
>> persistent memory handling features that could be better handled with
>> a more "memory" vs "device" perspective?  What are we trading off?
>> More importantly how do our current interfaces hold up when
>> considering new features?
>>
>> For example, how to support DAX in coordination with the BTT (atomic
>> sector update) driver.  That might require a wider interface than the
>> current bdev_direct_access() to tell the BTT driver when it is free to
>> remap the block.  A wider ranging example, there are some that would
>> like to see high capacity persistent memory as just another level in a
>> system's volatile-memory hierarchy.  Depending on whom you ask that
>> pmem tier looks like either page cache extensions, reworked/optimized
>> swap, or a block-device-cache with DAX capabilities.
>>
>> For LSF/MM, with all the relevant parties in the room, it would be
>> useful to share some successes/pain-points of the direction to date
>> and look at the interfaces/coordination we might need between
>> sub-systems going forward.  Especially with respect to supporting pmem
>> as one of a set of new performance differentiated memory types that
>> need to be considered by the mm sub-system.
>
> So do you want a BoF where we'd just exchange opinions and look into deeply
> technical subtleties or do you want a general session where you'd like to
> discuss some architectural decisions? Or both (but then we need to schedule
> two sessions and clearly separate them)? For the general session my
> experience shows you need rather clear problem statement (only the
> integration with BTT looks like that in your proposal) or the discussion
> leads nowhere...

Yes, I think there are two topics one suitable for a BoF and the other
that might be suitable as a plenary.  For the BoF, DAX+PMEM
developers, I want to look at this DAX with BTT question.  It is
interesting because the same interfaces needed to support DAX with BTT
would also enable cache management (*sync) in the driver like a
typical storage device, rather than the vfs.  In general, we seem to
be having an ongoing storage-device vs memory debate, so I expect the
discussion to be larger than this one issue.

Support for performance differentiated memory types needs wider
discussion.  I can put forward a device-centric management model as a
straw-man, but this does not address the higher order mm operations
like migration between memory types and transparent fallback that will
also be needed.  This is a follow on discussion from the session Dave
Hansen and I lead at kernel summit in Seoul.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux