On Wed, May 16, 2012 at 05:58:49PM -0400, Benjamin LaHaise wrote: > The big question I have is what the actual interface for these types of > memory will be. If they're like actual RAM and can be mmap()ed into user > space, it will be preferable to avoid as much of the overhead of the existing > block infrastructure that most current day filesystems are built on top of. Yes. I'm hoping that filesystem developers will indicate enthusiasm for moving to new APIs. If not the ones I've proposed, then at least ones which can be implemented more efficiently with a device that looks like DRAM. > If the devices have only modest endurance limits, we may need to stick the > kernel in the middle to prevent malicious code from wearing out a user's > memory cells. Yes, or if the device has long write latencies or poor write bandwidth, we'll also want to buffer writes in DRAM. My theory is that this is doable transparently to the user; we can map it read-only, and handle the fault by copying from NVM to DRAM, then changing the mapping and restarting the instruction. The page would be written back to NVM on a sync call, or when memory pressure or elapsed time dictates. -- 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
