On Tuesday 15 May 2012, Matthew Wilcox wrote: > > There are a number of interesting non-volatile memory (NVM) technologies > being developed. Some of them promise DRAM-comparable latencies and > bandwidths. At Intel, we've been thinking about various ways to present > those to software. This is a first draft of an API that supports the > operations we see as necessary. Patches can follow easily enough once > we've settled on an API. > > We think the appropriate way to present directly addressable NVM to > in-kernel users is through a filesystem. Different technologies may want > to use different filesystems, or maybe some forms of directly addressable > NVM will want to use the same filesystem as each other. ext2 actually supports some of this already with mm/filemap_xip.c, Carsten Otte introduced it initially to support drivers/s390/block/dcssblk.c with execute-in-place, so you don't have to copy around the data when your block device is mapped into the physical address space already. I guess this could be implemented in modern file systems (ext4, btrfs) as well, or you could have a new simple fs on top of the same base API. (ext2+xip was originally a new file system but then merged into ext2). Also note that you could easily implement non-volatile memory in other virtual machines doing the same thing that dcssblk does: E.g. in KVM you would only need to map a host file into the guess address space and let the guest take advantage of a similar feature set that you get from the new memory technologies in real hardware. Arnd -- 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
