On Tue, Jan 28, 2014 at 01:04:12PM -0800, James Bottomley wrote: > That rather depends on whether you think Execute In Place is the correct > way to handle persistent memory, I think? I fully accept that it looks > like a good place to start since it's how all embedded systems handle > flash ... although looking at the proliferation of XIP hacks and > filesystems certainly doesn't give one confidence that they actually got > it right. One of the things I don't like about the current patch is that XIP has two completely unrelated meanings. The embedded people use it for eXecuting the kernel in-place, whereas the CONFIG_FS_XIP code is all about avoiding the page cache (for both executables and data). I'd love to rename it to prevent this confusion ... I just have no idea what to call it. Somebody suggested Map In Place (MIP). Maybe MAXIP (Map And eXecute In Place)? I'd rather something that was a TLA though. > Fixing XIP looks like a good thing independent of whether it's the right > approach for persistent memory. However, one thing that's missing for > the current patch sets is any buy in from the existing users ... can > they be persuaded to drop their hacks and adopt it (possibly even losing > some of the XIP specific filesystems), or will this end up as yet > another XIP hack? There's only one in-tree filesystem using the current interfaces (ext2) and it's converted as part of the patchset. And there're only three devices drivers implementing the current interface (dcssblk, axonram and brd). The MTD XIP is completely unrelated to this, and doesn't need to be converted. > Then there's the meta problem of is XIP the right approach. Using > persistence within the current memory address space as XIP is a natural > fit for mixed volatile/NV systems, but what happens when they're all NV > memory? Should we be discussing some VM based handling mechanisms for > persistent memory? I think this discussion would be more related to checkpointing than it is VM, so we probably wouldn't have the right people in the room for that. It would probably have been a good discussion to have at kernel summit. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
